Last week I upgraded my computer changing everything except the hard drives. I’m typing this text from the new system already, having migrated my Linux installation to it, and having reinstalled Windows.
I always thought my previous system ran close to perfection, and the only reason for the upgrade was gaming. I wanted a new graphics card and, with it, I didn’t want other part of the system to be a performance bottleneck, so I ended up upgrading it almost completely. I’m now using an Intel Core i5-4690S, 8 GiB of RAM and an EVGA GTX 760 Superclocked ACX. The performance is just amazing, and the price very fair.
As I mentioned, I also migrated my Linux installation to this new computer. By migrating I mean I continue running the same system without reinstalling, preserving the state of the OS and personal data. It’s the third time I did such an operation, and it’s been at least ten or eleven years since I installed this system. I’ve been running the rolling release installation of Slackware Linux since then, across several computers.
I’ve never fully documented my migration procedure. The following notes serve mainly as a reference for myself in the future.
I start from the old system by first removing all custom kernel modules I have installed, which these days is mostly the binary NVIDIA driver. Then, I switch from a modular kernel with an initial RAM disk to a huge everything-included kernel that would be suitable to boot any system, including the new one for which I still don’t know which modules are essential to boot.
In Slackware there’s a specific package for that called kernel-huge. Just in case it’s useful, the kernel config and image file are easily available. I proceed to boot my old system with this kernel and without an initial RAM disk to check everything is fine.
I then proceed to transfer all data to the new computer. In this case it meant just plugging the old hard drive in the new computer, but it depends on the situation. The previous time I used an external USB hard drive to copy data from a laptop to my now-old desktop computer, which was booting from a Live-CD or Live-USB. If both systems have Gigabit Ethernet ports, a crossover cable can be a fast solution too.
In this step you may have decided to change the partitioning scheme to be used in the new system, so a bit of data juggling and temporary mounts may be needed. Once the new system has the data, 80% of the work is done and only the other 80% is left.
Finishing touches and booting
Time to try to boot the new system. For that, I usually chroot into the new system from a Live-CD or Live-USB. I first attempt to configure the bootloader correctly. I always install GRUB (these days v2) in the MBR of the appropriate hard drive the BIOS will try to boot. This will probably change with EFI, but I still run my system in Legacy BIOS mode (take into account my gaming OS is Windows 7).
The hard drive order as detected by the BIOS or GRUB may not match the order in the kernel. This happens in my new computer. hd0 and hd1, as detected by GRUB, match to /dev/sdb and /dev/sda respectively. I adjust the GRUB config file accordingly.
After installing GRUB, I pay attention to these other files and tweak everything until the system boots correctly.
/etc/fstab, paying attention to the new partitioning scheme, if any, and the hard drive names.
Remove autogenerated persistent udev configuration files. In Slackware they sit in /etc/udev/rules.d.
Tweak or disable personal commands run at boot time from rc.local and other scripts (no systemd yet in Slackware). Some of those may be related to specific kernel modules or hardware tuning.
Review the /etc/smartd.conf configuration file for possible changes or disable SMART until the new system is ready.
At this point I’m happy because I should be running my system in the new computer.
The next step is using mkinitrd-command-generator.sh from Slackware team member AlienBOB to find out which modules I need to boot the computer, and reverting to a modular kernel with an initial RAM disk.
Finally, re-enable or review everything that may have been temporarily disabled previously from boot scripts and SMART. Also, save a fresh copy of the new ALSA settings with “alsactl store”.
I then reinstall the NVIDIA driver and other binary kernel modules, re-configure X11 as needed and tweak any specific system scripts and tools I have stored in /usr/local/sbin and similar places, checking if anything needs to be changed or if there’s been a change in device names.
And that’s it. Typically it’s an evening’s work. Reinstalling Windows, on the other hand, and having to apply around 200 security updates takes ages, but at least it’s mostly unattended.
Sometimes people congratulate me for youtube-dl, specially on Twitter. I stepped down as the maintainer long ago, but I’ve given commit access to the repository to a few people who are doing a superb job at keeping the program up-to-date, supporting sites and adding whatever new features users come up with!
The list increases with time as the current maintainers ask me to add new developers. I wanted to have a post like this, so I can refer to it when people congratulate me.
The current list of people with commits access follows, and does not include occasional contributors, who should be thanked too.
Jaime Marquínez Ferrándiz.
mpv is essentially the same video player. It’s based on code from MPlayer and mplayer2, so it behaves more or less like you expect. That means it plays almost everything you throw at it thanks to the ffmpeg libraries, it starts instantly (sorry, VLC, I’ll still recommend you to friends and family!) and the command line options look familiar, even if they have been changed into more standard forms.
Deeper changes include major codebase cleanups, a high quality OpenGL video output driver with higher-precision color transformations, a reworked build system and using system libraries instead of including them in the program source code.
For someone like me who builds all the multimedia toolchain from sources, it’s an advantage. When ffmpeg releases a new version I build that first, and I don’t have to download a second copy and build it again while building MPlayer. mpv uses what’s available. It’s the same for libass or x264, the latter being an example of external library not included when you download the MPlayer source.
This results in much faster compilation times and a much improved situation for packagers, in my humble opinion.
The icing that tops the cake are periodic releases, so you know exactly when you should upgrade as developers mark interesting points in the project history.
And the only drawback is the surprising muscle memory. After more than 10 years typing “mplayer” and with “mpv” sharing a common two-letter prefix, it’s amazing how most times I have to focus a lot to type “mpv” correctly.
A couple of days ago my wife and I went to the talk Dmitry Glukhovsky gave in the Celsius 232 festival about his upcoming novel, Furu.re. We took the opportunity of getting a copy of Metro 2033 signed by its author, and the corresponding picture just like last year we did with David Simon. Coincidentally, the book signing took place in the same booth.
I must confess I haven’t read the book yet. I only knew the videogame, and interest in the novel only came to me after hearing he was coming to the festival. The videogame is pretty average, in my humble opinion, and I always thought it required too many resources for the graphics quality it offered, but recently I read several reviews suggesting the "hardcore ranger" mode made the game much more interesting and satisfying, emphasizing the survival aspect. Just a few months ago I replayed it and I have to agree. Naturally, it’s more difficult in that mode, but very far away from frustrating.
I have a copy of Metro: Last Light in my Steam account, but it’s still sitting in my pile of pending games.
Futu.re was enthusiastically presented by the talk director and praised as Glukhovsky’s best novel so far, bar none. The background is a future were humankind has finally reached biological immortality, and tries to answer the questions evoked by that premise.
The superstar of the festival this year was Patrick Rothfuss, author of The Kingkiller Chronicle trilogy, who got people waiting in line for hours to get a signed copy of one of his books, and a packed auditorium during his talk.
The second game I wanted to review during this Steam Summer Sale is Bioshock Infinite, the third installment in the Bioshock series.
Bioshock Infinite was widely praised critically and a commercial success judging by the number of copies sold, more than 6 million. Apparently, that was not enough for what Irrational Games had in mind, because the studio closed in February 2014.
While Infinite’s metacritic score is 94/100, I’m giving it a much lower score for reasons that I’ll explain below.
Technically, the game is almost perfect. It has high resolution textures that barely blur when you’re close to them, its own atmosphere and graphics style, and every corner in every level has been looked at and polished. Audio is also fantastic and musical elements have been integrated into the gameplay, like the note that plays when you give the final blow to an enemy. To get this out of the way, it’s a 9.5.
Gameplay, on the other hand, is just not remarkable. As we’re used to from other games in the Bioshock series, characters are very well developed thanks to the audio logs you can find throughout your adventure, and the story has depth. I’m not questioning that, but many story and gameplay elements are borrowed from other Bioshock games. A city built outside the reach of governments, a benefactor, the audio logs, the scientific-magic investigations and powers, the smuggling and decadence…
The gameplay style also suffers from the problems I exposed in my Far Cry 3 review: you feel directed inside a movie instead of the story developing in front of your eyes. Also a bit disappointing are the poor weapon expansions and power improvements, or the fact that you can only carry two weapons at the same time. At least in hard mode, some of them are also very underpowered. I found the sniper rifle and carbine to be the best weapons, closely followed by the hand cannon, but the rocket launcher sometimes needs two impacts to kill a relatively normal enemy. It’s simply not worth carrying that around given the limited maximum ammo. Shotguns, a favorite of mine in most videogames for close and medium range combat, feel handicapped in Bioshock Infinite.