Alien Pastures

My thoughts on Slackware, life and everything

Category: Hardware (Page 4 of 5)

My (first) Raspberry Pi arrived in the post

July 26, 2012 / / 20 Comments

 At last…

I ordered a Raspberry Pi on May 11, 2012 and Farnell/Element14 delivered it to my home while I was on vacation. Go figure. The postman did not find us home of course, and rang our neighbors’ doorbell. He left the package there, and luckily that neighbor brought me the package the moment he saw our car parked in front of the house.

The little computer came wrapped in a Raspberry Pi T-shirt (with Element14 written all over the front as well) but hey – the T-shirt was free and it served well as wrapping instead of bubble plastic

 

Planning-wise, the Raspberry Pi arrived at an awkward moment. I had not expected delivery until well into august, and intended to pick up my own ARM port of Slackware after my return from France (targeting more recent CPUs than the Raspberry Pi, i.e. an ARM port of Slackware which will be incompatible with the Raspberry Pi). Having the computer in my hands, I could not put it aside, and proceeded with gathering everything needed to make it run Stuart Winter’s ARMedSlack.

The work I intended to do when I wrote my original blog post about the Raspberry Pi (back in November 2011) has been done already. Using ARMedslack as the base distro, David Spencer setup a web space where he writes in great detail how to install ARMedslack on the RasPi. He has created a bootable install image – to be copied onto a SD card – and maintains all his packaging and scripting work on Github.

So I bought a SD card – a Raspberry Pi does not have any internal storage – and dd-ed the installer image to the card. Inserted the card into the Raspi, connected a HDMI cable to my television, attached a USB keyboard with built-in TrackPoint mouse, plugged in a LAN ethernet cable and finally used my phone charger (micro USB) to power it up.

First, a fancy display of colours is visible on the television screen, probably the GPU’s bootloader showing off, and then a Linux kernel with the image of good old Tux replaced by a Raspberry was booting up. The long and boring process follows… formatting the root partition takes ages (which is actually expected behaviour, considering the hardware) and installing the packages is still ongoing while I am typing this:

I guess I will have to be patient. In the meantime I can think of good uses for a second device which should be delivered next week. Will it be good for an XBMC based media streamer? Will I put the semi-official Debian image on that one to see how the two distros differ? I have no idea yet. But just holding a 30 euro computer knowing that it will be running Slackware tomorrow brings a smile to my face.

When I have more to tell you, I will write another post. Now it is time to go to sleep, in the hope that the installation has finished by tomorrow morning so that I can bring the Raspberry Pi along when driving to the office.

Cheers, Eric

Raspberry Pi deserves Slackware

November 27, 2011 / / 31 Comments

Some time ago I ran into this website promoting a very cheap computer the size of a credit card. The Raspberry Pi is being created by a charitable foundation. It is designed to “plug into a TV or be combined with a touch screen for a low cost tablet“. Typically its target is “teaching computer programming to children“, but such a cheap computing device will certainly have “many other applications both in the developed and the developing world“.

You have to see the device to believe it, I guess. The videos and photos look very promising. It’s not in production yet but according to the developer team’s schedule first shipments should commence before the end of the year.

Its specifications are not stellar (256 MB of RAM will likely rule out the top-heavy desktop environments like KDE) but hey! it only costs 35 euros! And the ARM processor, a Broadcom BCM2835 SoC with a ARM1176JZF-S core seems to have good support in the Linux kernel (a patch that adds support to linux-3.0.4 is fairly trivial). Check out this video which shows the Raspberry Pi running Quake III in 1920×1080 resolution with 4x antialiasing.

There is a thread on LinuxQuestions which shows that it may in fact not be hard to boot Slackware – or rather, ARMedslack. Using the latest QEMU which supports the Broadcom’s ARM version, and a recent kernel compiled for ARM (see above), QEMU can successfully boot one of ARMedslack’s “mini rootfs” filesystem images.

So, I think that the Raspberry Pi deserves Slackware. If we are going to bring Slackware to the masses, this ARM device would be a nice vehicle. I am going to get myself one or two of them. Stuart Winter (ARMedslack developer) promised to help me with the nasty bits. We will see how this ends up – either incorporated into ARMedslack, or as a separate development tree hosted by me, or (nicest option but not a very realistic one perhaps) folded into the main Slackware tree. It would be cool to have the main tree expand to support a third architecture besides x86 and x86_64.

Cool, another project for my evergrowing TODO list! Oh my… I can’t even find the time to spend on another project that is itching at the back of my mind… I guess should at least make an effort to upload all of the OCR related packages I created a month ago.

Eric

Digitizing my paperback books

October 4, 2011 / / 12 Comments

Part one: what do I want?

I hinted at this topic in a previous post. I have a big collection of (mostly) paperback Science Fiction books – some hardcover books too. I used to read a lot more in the pre-Internet days, nowadays it’s just during my holidays that I get enough time to read whole books in a short enough time… so many of those old paperbacks are 20-30 years old and yellowed.

In this digital age it would be appropriate to have digital versions of my books and save them from crumbling to dust. I am in anticipation of Sony’s new e-reader, the PRS-T1 which I want to buy once it is out:

This is a very nice device. It is also a lot cheaper than the previous generation Sony e-reader (the PRS-650) while at the same time adding wireless connectivity. This device needs content once I have it in my possession.

A lot of the “newer” books, and those written by contenporary authors can be purchased online, or downloaded from fan sites where people scan their own collections into EPUB or MOBI e-books.  That is all good and well, but on my bookshelves I have many dozens good books that will probably never see a new life as an e-book. That is very unfortunate… I had a lot of fun reading them and do not want to see them go into oblivion.

I decided to do something about this. I am going to try and describe (and hopefully implement) how I am going to digitize my book library. Note: at the moment this is all just ideas, “dreams” if you wish, although I have already found quite a bit of information on the Internet that I will be sharing with you. I want it to be more than just a dream.

What does one need to get a paper book converted into an e-book?

  1. the book’s pages need to be scanned
  2. the scanned bitmaps may have to be cleaned-up digitally (enhancing the contrast between characters and background, de-skewing or rotating the text blocks, …)
  3. I need an Optical Character Recognition (OCR) program to convert the bitmap images into character text
  4. I need an e-book editor to layout the bare text that I got from the OCR program – the ebook has to look largely like the original paper version.
  5. I want to use a library program to make my book catalogue available, to myself of course, to my e-reader device, and possibly to other interested parties.

And I want this to be as low-cost as possible. Any software that I am going to use for this should preferably be Open Source and run on Slackware.

Those are the main topics I will write about. Each of these topics deserves its own separate article. Why is that?

I can already see how this project will confront me with interesting challenges. I am going to write a multi-post story with interlinked articles (this being the first) in order to preserve this hobby project of mine for posterity. Having separate topic articles allows me to split up your feedback as well (heh… I hope I do get some feedback!), so that discussions about, say, scanning techniques will not interfere with talk about what is the best OCR program for Linux.

The articles are not going to be “static” per se. I value your feedback and important new insights will find their way back into the main text.

Let’s see where this ends. It is probably going to take days, or weeks,  to write. It delends a bit on Slackware development – if that picks up speed again, I will have less time for this ebook side show. But for the moment , there is silence in the ChangeLog.txt and I have time to spare.

Eric

E-book management on Slackware

June 19, 2011 / / 23 Comments

Managing your e-book collection

In an earlier post, I hinted about a Slackware package I was trying to create for Calibre. The reason being that I bought my wife an e-reader: a Sony PRS650 with a touch screen using infrared instead of a touch-sensitive layer and pearl e-ink technology. Both those features make for an extremely pleasant reading experience.

However, the Sony Reader software that accompanies the device, is a Windows-only application (of course…) and second, it is not all that much of an application either. Even for Windows, the usual advice you get it is to install Calibre for  managing your e-books – including uploading them to your device.

So, I needed to have Calibre available on my Slackware computers. In fact, I used to have a package for Calibre already! At some point in time the Calibre developer decided to increase the required version of the Python interpreter to 2.7.1. And since Slackware ships Python 2.6.6 to this day, I was no longer able to compile updated packages  (I got stuck at 0.7.23 but I guess it would have been possible to keep compiling Calibre as far as 0.7.45).

I still wanted a recent version of Calibre, the software has updates about once a week! So I spent quite a lot of time researching how I could add an embedded Python interpreter plus several supporting Python modules into the Calibre package.

And I think I succeeded. I have uploaded Slackware packages for calibre-0.8.6 to my repository yesterday (for Slackware 13.1 as well as Slackware 13.37). During the period where I did not actually have an e-reader at my disposition (it arrived at the house only a few days ago) I used the testing genius of my pal mrgoblin who happened to have an e-reader device in his possession. His beta tests made me realize that I was missing the dbus-python module which is needed for Calibre to recognize when a device is plugged into the computer.

I must say, using Calibre is a lot of fun! I have a small collection of e-books and after installing the Slackware package, I was able to transfer my books to the Sony device and read them there. Then, I managed to almost brick the device by ripping out the USB cable before selecting “Eject Device” in Calibre… let that be a warning for prospective users! It took a lot of reading about soft and hard resets before I had a working e-reader again. I had to reset the device to factory defaults – which means you lose all the books that were already present on the device. It was a good learning experience with only minor inconvenience (because I had transfered only two books to the e-reader at the time) but I kept feeling my wife’s prying eyes in the back of my neck… she was not too pleased with seeing her birthday present getting bricked only 15 minutes after unpacking it!

Calibre will also be very useful for everyone who owns a Kindle (Amazon’s own e-reader). The Kindle only accepts Amazon’s own MOBI format and refuses the “open” EPUB format (which is the most commonly used e-book format outside the US). Using Calibre, you can easily convert your EPUB collection to MOBI format – when you select an EPUB file and tell it to upload it to a Kindle, Calibre will show a dialog that prompts for the automatic conversion to the Kindle’s format. Perfect!

OK, enough talk. Get a package and/or SlackBuild script at:

and don’t forget to also install the icu4c and podofo packages; these two are the only dependencies now. If you want to build the package yourself, be warned if you are running Slackware-current. There is a bug in the “file” utility in Slackware-current which prevents it from recognizing a ZIP file as such, and this bug will cause the SlackBuild script to fail. Thanks to Francesco Allertsen who first ran into this issue and reported it to me, a quick fix is to change the line 235 in the calibre.SlackBuild script:

if $(file ${SOURCE[$i]} | grep -qi “: zip”); then

to:

if $(echo ${SOURCE[$i]} | grep -qi “.zip$”); then

I hope to see a fixed “file” soon. A bugfix has been applied to the file repository already, so file-5.08 should detect ZIP files correctly when it gets released.

Have fun! Eric

Wireless Ethernet Bridge

March 27, 2011 / / 10 Comments

This weekend, I setup a Wireless Ethernet Bridge.

What the heck, I hear you say! I’d better explain why I did this, and what it actually means.

I have a wireless network in the house that extends to a large part of the rooms. Unfortunately we have thick walls and ceilings with a lot of steel-reenforced concrete, and this causes less-than-ideal wireless reception in parts of the house. The thick concrete walls do not invite drilling a lot of holes for CAT5 cables. I had to think of something else that minimized the drilling of holes and still gave me a network that covers all of the house.

I have been using a WRT54GL (its selling point being that it can easily be flashed with alternative Linux based firmware) until now. This gave me a wireless speed of 54 Mbit/sec (802.11g) maximum. I have flashed this router with an alternative firmware, tomato, which really helped me getting my Internet router stable and feature-rich while at the same time I was able to raise the transmission power a bit… but not enough.

Linksys WRT54GL

So what I did was to buy a new wireless dual-band router with 802.11n speeds (300 Mbit/sec) which gives the existing wireless LAN a boost. This new router had to be capable of running tomato firmware too (because I am fond of it) and the dual-band gave me a way to leverage the old WRT54GL without killing the speeds of the larger wireless LAN: a dual-band router basically has two wireless access points built-in. I found the Cisco/Linksys E3000EW at a very interesting price (it is being followed up by a new device, the E4200). It also has an USB port (for connecting a hard drive or a printer) and I found that the tomatousb firmware (a successful mod of the tomato firmware) fully supports this device.

Cisco/Linksys E3000-EW

The E3000EW was switched on and two minutes later, the poor bugger was running tomato firmware! A firmware upgrade through HTTP upload using the standard Linksys firmware worked flawlessly.

Now the first task was to copy the configuration of the old WRT54GL to the new E3000EW. That was not too hard. AlsoI setup the two internal access points with two different ESSIDS of course. Then I quickly swapped the two (after “cloning” the WAN MAC address so that I would not have to go through my ISP’s provisioning setup again) and I had freed the WRT54GL for re-configuration into a Wireless Ethernet Bridge.

What was my plan? To position the WRT54GL in the house, nearby the area where wireless signals were weak because of the steel and concrete. Its position would be where I do have a good wireless connectivity. From that point on, I would run CAT5 cable from the WRT54GL to the computers that needed to be connected. This would mean, much less cable and much less drilling.

Actually, that was the final plan, which I implemented. Originally I wanted to create a distributed wireless network using WDS, which is a technique (supported by the tomato firmware) to connect multiple wireless access points. However, when I started reading about these techniques, it turned out that WDS effectively cuts your wireless network speeds in half with every “hop” that you create in your network. And I was not prepared for lower speeds… even though the advantage would be that I did not have to run new CAT5 cables. Access points with WDS still accept client connections, so all I would have to do was put the second AP in a location where it gave good coverage to the computers that suffered from problematic wireless reception.

The thing with Wireless Ethernet Bridging (WET) is this: the second Access Point, deployed to connect to the “master” and create the bridge, dedicates its wireless link to that bridged connection. It will no longer accept connections from wireless clients. It means that the computers need to connect to it using conventional cable!

It was a matter of weighing the pros and the cons. I decided on creating the bridge and using cables, because that would keep the maximum network speed acceptible.

So the old WRT54GL was reconfigured (using a network cable of course, you can not do this wirelessly). And it works surprisingly well! I am writing this article while my laptop is connected to this device using a cable and the traffic is bridged across the air. So, whoopee!

There are a few gotcha’s that I ran into, before I finally found out what it takes to successfully create a wireless bridge.

  • The “master” router (the E3000EW in this case) needs to be configured as a Wireless Access Point – that is the default, so I could leave that one alone.
  • The secondary router (the WRT54GL) needs to be configured, not as a gateway but as a router (in the tomato’s Advanced > Routing menu) or else your traffic is not going to reach the “master” router at the other end of the bridge.
  • The wireless security must be set to “WPA Personal”, with AES encryption (in the tomato’s Basic > Network menu). I had left this setting to “WPA/WPA2 Personal” at first, using AES for ecryption (this was what I used when the WRT54GL was still my Internet router), and it would refuse to connect to the wireless master. If you look more closely to the dropdown menu for the security settings, you’ll see that the tomato warns that WPA is the only accepted choice…
  • The WRT54GL can function as a wireless bridge without having an IP address assigned to it. However, you lose the ability to make a HTTP connection to the administrative interface – and someday that will prove to be very inconvenient. So I gave the router an unused IP address from my LAN address range.

Remember, when you setup a bridge, you are extending your network transparently. A network bridge passes network packets back and forth without dividing the network in two segments. Computers in the LAN will be unaware of the bridged connection – it does not show up in a traceroute. There is another solution for my problem that I have not gone deeper into, and that is to setup the WRT54GL as a “wireless client”. This creates a new network segment though… which requires that you run a DHCP server on the WRT54GL for the wired client computers that you connect to the device.

And yet another option is to install the “dd-wrt” firmware and configure the WRT54GL as a Wireless Repeater which allows you to connect your computers wirelessly to the device… but dd-wrt is not nearly as userfriendly as tomato. Pick your choice.

This is the network diagram I ended up with (courtesy of oldspeak where I also obtained the final piece of the puzzle):

Wireless Ethernet Bridge

And what about powerline / homeplug, you ask?

I have considered that, and sometime ago, when my wireless conneciton problems became aggravating, I even wanted to buy a set of 200 Mbit Devolo mini adapters. They would give me 100 Mbit effective network speeds, but I still would have to buy a second wireless access point if I wanted to extend my wireless LAN, or else I would have had to use conventional cable. That made me decide to pick the geeky solution.

Eric

« Older posts Newer posts »

© 2025 Alien Pastures

Theme by Anders Noren — Up ↑