I recently bought a Samsung SSD to replace my HDD in my Arch Linux notebook. It is a “Samsung SSD 840 EVO 2.5 Zoll SATA”. One of the first things I do when I get new hardware is to make sure the latest firmware is installed. Mine did not have the latest firmware update and – as it was to expect – Samsung SSD firmware updates under GNU/Linux are not (officially) supported. Samsung ships only Microsoft Windows software, called “Magician”, which can directly update the firmware or create a live USB-Stick to do the update. Additionally, they provide *.iso image files (one for Microsoft Windows systems and one for Apple computer, respectively) to update the firmware from a live CD. The *.iso image file intended for Microsoft Windows would also work under GNU/Linux, only that my notebook does not have a CD Drive anymore. Obvioulsy, the only option left was to create my own live USB-Stick under GNU/Linux – without using Microsoft Windows and that crappy Samsung “Magician” software. A simple “dd” comand to “burn” the *.iso file on an USB-Stick did not do the trick, as the Isolinux version Samsung uses is over 10 years (!) old.
This article shows how to update the firmware of a “Samsung SSD 840 EVO 2.5 Zoll SATA” under GNU/Linux using a bootable live USB-Stick.
There is a lot of confusion and wrong information in the internet about the Unified Extensible Firmware Interface (UEFI) and how to set it up correctly – especially under GNU/Linux. What makes things worse and also confused me a lot is that all vendors tend to implement this “standard” differently. So although UEFI is defined as a new industry standard replacing the BIOS, it can hardly be called “standard” at this time. Yet another problem of understanding UEFI is, that people seem to mix up words that have a special meaning.
My old notebook still uses the old BIOS-MBR setup, not capable of any UEFI fancy-ness. But it is dying, so I recently bought a new one. It is an “HP EliteBook 840 G1”. I used that opportunity to familiarize myself with UEFI and GNU/Linux.
This article explains two things (only taking GPT setups into account):
How is UEFI implemented in practice and set up with GNU/Linux?
I often have to read a lot of code from other people that is not exactly well written or easily understandable. I am working on several different projects; some open-source for fun & giggles and some closed-source for money & fame. I just noticed that the biggest problem in understanding other peoples code is not about things you could easily measure, like code quality in the sense of code formatting standards or the language that it is written in. Naming of constants and variables make all the difference for understanding the code others have written.
I realized, that there are some words which should just be forbidden to use on their own. They are too broad or just don’t add any valuable information. I am also very sorry that these following examples contain PHP code, but this is where examples for doing things wrong are easily found. Most of the example code listings are not good practice in other senses as well, but that’s not what this post is about; It’s about the kind of readability which applies to all programming languages.
I just wanted to finish a draft blog post using my tablet, since after all, it’s a full blown computer. It has more than enough horsepower to run virtually any writing application. But right after I began to type in letter by letter, I realized that touch screens make you lazy. So lazy, that the blog post would have become much shorter than I wanted it to be. Additionally it would have included strange auto-completion artifacts and misplaced punctuation not resembling my usual writing style. Let’s explore the brave new world of touch screen computing, why touch screens suck and how they make us to internet zombies.
Since USB-Sticks, that are fast and have a high capacity, are finally affordable, I decided to buy a new one. I usually install a GNU/Linux live CD (more precisely live USB) distribution on my USB-Sticks: either SystemRescueCd or Kali Linux (former Backtrack). The left over space is used for the classical purpose of an USB-Stick – data exchange. Todays USB-Sticks have enough capacity to easily fit several GNU/Linux live distributions on them, while still leaving enough space for other data. So my plan was to create a multiboot USB-Stick, that would boot my favourite GNU/Linux live distributions mentioned above. Unfortunately, searching the internet for implementing this did not give me any satisfactory results. There are a ton of guides that explain how to create an USB-Stick that boots GNU/Linux, but there are almost no multiboot solutions. The few howto’s about multiboot USB-Sticks are either about booting *.iso files (which only works with some GNU/Linux distributions) with GRUB 2 (which is designed for static boot setups anyway) or require further customized modifications of the GNU/Linux live distributions. I wanted a simpler solution that – once created – allows for easy updating of the installed GNU/Linux live distributions.
This guide will explain how to create a multiboot USB-Stick that can boot several GNU/Linux live dirstibutions via Syslinux chainloading. It will have several partitions (one for each OS and one for the main Syslinux bootloader) and a separate data partition, that can be formated independently in any way you like, so that your data is seperated from the operation system data. This guide installs SystemRescueCD and Kali Linux on your multiboot USB-Stick, but any other GNU/Linux live distribution should work as well. Adding more than two OS should also be no problem.
Everybody knows the code on the screens in the movie the matrix. You can see it for example when the character “cypher” talks to “neo” somewhen in the night, and the green letters fall down on those second-hand dell screens behind them. Funky. I want that too.
I’ve written a python program that uses curses to create a similar looking animation and just now cleaned up the code a bit and made sure it runs in python 2 and 3. You can get the source code on github and there’s a screenshot and a short explaination after the break…
I am a big fan of the old Japanese board game Go. Some time ago I wanted to get my own Go game, consisting of a Go board (goban) and black and white stones. Unfortunately, I found out that wooden Go boards are quite expensive, by far exceeding the price range I was willing to pay. Actually, gobans are quite a simple piece of equipment. It is nothing more than a (wooden) board with a grid of 19 x 19 lines on it, why should I pay over 100 euro for it? So I decided to build my own and just buy the stones, which are cheap to come by.
If you’re into python, but don’t know about PEP8 or PyLint, you should find out right now. And because pep8 and pylint are great, but it’s hard to force yourself to use them all the time, lets integrate them into geany, a fast and lightweight IDE.
I’ve received my rPi a while ago, but never wound up doing much with it. Recently I have received another screen which is a little older, but still features a DVI input. Since developers can’t have enough screen space and my laptop has only one VGA output, I decided to use the raspberry pi as my ethernet-to-DVI adapter.
This how-to is composed of two parts, first I explain how to get synergy up and running, and then how to set up your VNC to help the illusion that everything is happening on the same computer.