Archive

Archive for the ‘Linux’ Category

Extract album art from MP3 files

May 7th, 2016 No comments

Recently I needed to extract the album art from an MP3 file and came across a really easy to use command line utility called eyeD3 to do just that (among other things). Here is how you can extract all of the album art from a file MyFile.mp3 into a directory called Output.

1) Install eyeD3

sudo apt-get install eyeD3

2) Extract all embedded album art from the file

eyeD3 --write-images=Output/ MyFile.mp3

Pretty simple!




I am currently running a variety of distributions, primarily Linux Mint 17.
Previously I was running KDE 4.3.3 on top of Fedora 11 (for the first experiment) and KDE 4.6.5 on top of Gentoo (for the second experiment).

KWLUG: Docker Tutorial (2016-04)

April 23rd, 2016 No comments

This is a podcast presentation from the Kitchener Waterloo Linux Users Group on the topic of Docker published on April 5th 2016. You can find the original Kitchener Waterloo Linux Users Group post here.

Read more…




I am currently running a variety of distributions, primarily Linux Mint 17.
Previously I was running KDE 4.3.3 on top of Fedora 11 (for the first experiment) and KDE 4.6.5 on top of Gentoo (for the second experiment).

KWLUG: Mastering Photo DVDs, KDEnlive (2016-03)

March 8th, 2016 No comments

This is a podcast presentation from the Kitchener Waterloo Linux Users Group on the topic of Mastering Photo DVDs, KDEnlive published on March 8th 2016. You can find the original Kitchener Waterloo Linux Users Group post here.

Read more…




I am currently running a variety of distributions, primarily Linux Mint 17.
Previously I was running KDE 4.3.3 on top of Fedora 11 (for the first experiment) and KDE 4.6.5 on top of Gentoo (for the second experiment).

Murdering misbehaving applications with xkill

March 5th, 2016 No comments

Have you ever had a window in Linux freeze on you and no matter how many times you tried to close it, it just wouldn’t go away? Then when you try and find the process in System Monitor (or the like) you can’t seem to identify it for whatever reason?

Thankfully there is a really easy to use command that lets you simply click on the offending window and POOF!… it goes away instantly. So how does it work? Let’s say you have a window that is frozen like this

As long as you can see it you can kill it!

As long as you can see it you can xkill it!

First open up a new terminal window and type the command

xkill

and hit Enter. This will then tell you to simply click on the window you want to kill:

Select the window whose client you wish to kill with button 1….

Next it is as simple as actually clicking on the frozen window and you can say goodbye to your problem. Happy xkill-ing 🙂

This post originally appeared on my website here.




I am currently running a variety of distributions, primarily Linux Mint 17.
Previously I was running KDE 4.3.3 on top of Fedora 11 (for the first experiment) and KDE 4.6.5 on top of Gentoo (for the second experiment).

Limit bandwidth used by a command in Linux

February 28th, 2016 No comments

If you’ve ever wanted to run a bandwidth intensive command (for example downloading system updates) but limit how much of the available bandwidth it can actually use then trickle may be what you’re after.

Simply install it using

sudo apt-get install trickle

and then you can use it with the following syntax

trickle -d X -u Y command

where X is download limit in KB/s, Y is the upload limit in KB/s and command is the process you want to start limited to these bandwidth constraints. For example if I wanted to start a download of the latest (as of this writing) AMD64 VirtualBox for Ubuntu using wget but limit it to only using 50KB/s down and 20KB/s up then I would run

trickle -d 50 -u 20 wget http://download.virtualbox.org/virtualbox/5.0.14/virtualbox-5.0_5.0.14-105127~Ubuntu~trusty_amd64.deb

I should point out that trickle does it’s best to limit the bandwidth to what you select but often won’t be exact in how it does this. Either way it is another cool little tool for your Linux toolbox.

This post originally appeared on my website here.




I am currently running a variety of distributions, primarily Linux Mint 17.
Previously I was running KDE 4.3.3 on top of Fedora 11 (for the first experiment) and KDE 4.6.5 on top of Gentoo (for the second experiment).
Categories: Linux, Tyler B Tags:

Setting up Syncthing to share files on Linux

February 21st, 2016 No comments

Syncthing is a file sharing application that lets you easily, and securely, share files between computers without having to store them on a third party server. It is most analogous to BitTorrent Sync (BTS) but whereas BTS is somewhat undocumented and closed source, Syncthing is open source and uses an open protocol that can be independently verified.

This is going to be a basic guide to configure Syncthing to sync a folder between multiple computers. I’m also going to configure these to start automatically when the system starts up and run Syncthing in the background so it doesn’t get in your way if you don’t want to see it.

Download and Install

While it may be possible to get Syncthing from your distribution’s repositories I prefer to grab it right from the source. So for example you can grab the appropriate version for your Linux computer (for example the 64 bit syncthing-linux-amd64-v0.12.19.tar.gz download) right from their website.

Extract the contents to a new folder in your home directory (or a directory wherever you want it to live). One important thing to note is that you want whatever user will be running the program, for example your user account, to have write access to that folder so that Syncthing can auto-update itself. For example you could extract the files to ~/syncthing/ to make things easy.

To start Syncthing all you need to do is execute the syncthing binary in that directory. If you want to configure syncthing to start without also starting up the browser you can simply run it using the -no-browser flag or by changing this behaviour in the settings.

If you are on Debian, Ubuntu or derivatives (such as Linux Mint) there is also an official repository you can add. The steps can be found here but I’ve re-listed them below for completeness sake:

# Add the release PGP keys:
curl -s https://syncthing.net/release-key.txt | sudo apt-key add -

# Add the "release" channel to your APT sources:
echo "deb http://apt.syncthing.net/ syncthing release" | sudo tee /etc/apt/sources.list.d/syncthing.list

# Update and install syncthing:
sudo apt-get update
sudo apt-get install syncthing

This will install syncthing to /usr/bin/syncthing. In order to specify a configuration location you can pass the -home flag which would look something like this:

./usr/bin/syncthing -home="/home/{YOUR USER ACCOUNT}/.config/syncthing"

So to set up syncthing to start automatically without the browser using the specified configuration you would simply add this to your list of startup applications:

/usr/bin/syncthing -no-browser -home="/home/{YOUR USER ACCOUNT}/.config/syncthing"

There are plenty of ways to configure Syncthing to startup automatically but the one described above is a pretty universal method. If you would rather integrate it with your system using runit/systemd/upstart just take a look at the etc folder in the tar.gz.

Here is an example of my Linux Mint configuration in the Startup Applications control panel using the command listed above:

It's easy enough to get Syncthing started

It’s easy enough to get Syncthing started

Configure Syncthing

Once Syncthing is running you should be able to browse to it’s interface by going to http://localhost:8080. From this point forward I’m going to assume you want to sync between two computers which I will refer to as Computer 1 and Computer 2.

First let’s start by letting Computer 1 know about Computer 2 and vice versa.

  1. On Computer 1 click Actions > Show ID. Copy the long device identification text (it will look like a series of XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-…).
  2. On Computer 2 click Add Device and enter the copied Device ID and give it a Device Name.
  3. Back on Computer 1 you may notice a New Device notification which will allow you to easily add Computer 2 there as well. If you do not see this notification simply follow the steps above but in reverse, copying Computer 2’s device ID to Computer 1.
Once both computers know about each other they can begin syncing!

Once both computers know about each other they can begin syncing!

In order to share a folder you need to start by adding it to the Syncthing on one of the two computers. To make it simple I will do this on Computer 1. Click Add Folder and you will see a popup asking for a bunch of information. The important ones are:

  • Folder ID: This is the name or label of the shared folder. It must be the same on all computers taking part in the share.
  • Folder Path: This is where you want it to store the files on the local computer. For example on Computer 1 I might wan this to be ~/Sync/MyShare but on Computer 2 it could be /syncthing/shares/stuff.
  • Share With Devices: These are the computers you want to share this folder with.

So for example let’s say I want to share a folder called “CoolThings” and I wanted it to live in ~/Sync/CoolThings on Computer 1. Filling in this information would look like this:

syncthing_folder_setup

Finally to share it with Computer 2 I would check Computer 2 under the Share With Devices section.

Once done you should see a new notification on Computer 2 asking if you want to add the newly shared folder there as well.

Syncthing alerts you to newly shared folders

Syncthing alerts you to newly shared folders

Once done the folder should be shared and anything you put into the folder on either computer will be automatically synchronized on the other.

If you would like to add a third or fourth computer just follow the steps above again. Pretty easy no?

This post originally appeared on my website here.




I am currently running a variety of distributions, primarily Linux Mint 17.
Previously I was running KDE 4.3.3 on top of Fedora 11 (for the first experiment) and KDE 4.6.5 on top of Gentoo (for the second experiment).

Installing ROS on a Raspberry Pi

February 21st, 2016 No comments

As a lover of technology, I tend to accumulate bits and pieces of interesting devices. Usually, these are purchased for use on unrelated projects, and on occasion, I have the opportunity to bring them together into a single project in a previously unanticipated way. Such is the case with my Arduino and Raspberry Pi. Both are interesting microcomputers with their own strengths and weaknesses, so it was when I learned that they could be made to work together with the help of Robot Operating System, I had to give it a shot.

My raspberry pi

ROS is an open-sourced project that is dedicated to providing a framework of libraries for performing common tasks under the general heading of robotics. It also includes drivers that allow you to easily interface with common hardware. The core of ROS is a reactor model of observables and observers that send messages to one another, typically over a serial connection, allowing any number of controllers to interface with one another and form a unified whole.

The rosserial_arduino library is a project that allows ROS on a Raspberry Pi (or other *nix device) to interface with an Arduino over a USB serial connection, thereby combining the computing power and versatility of a Linux-based microcomputer with the IO capabilities of an Arduino.

What You’ll Need to Get Started

Installing Raspbian on the Pi

If your Pi already has an operating system on it, you can probably skip this step. If, however, it’s straight out of the box, you’ll need to install the Raspbian distribution.

As of this writing, the latest version of Raspbian is Jesse, released in September of 2015. I wasn’t able to get ROS working with this version, and backed down to the Wheezy release from May of 2015 instead. To install the operating system, I did the following:

  1. Download the Raspbian Wheezy image via a bittorrent client.
  2. When the download is complete, follow these instructions to copy the image file to your MicroSD card.
  3. Unmount the card, insert it into your Pi, and hook up the power. Your device should boot into a command prompt. From here, you can run raspi-config to customize the installation, or get right to installing ROS.

Once the installation is complete, be sure to check for updates:

pi@raspberrypi ~ $ sudo apt-get update
pi@raspberrypi ~ $ sudo apt-get upgrade

An up to date system is a safe system.

SSH

Once your Pi has an operating system, you can switch to interacting with it via SSH. My TV is the only “monitor” in my house that has an HDMI input on it, so SSH works much better for me.

Make sure that sshd is running on your Pi:

pi@raspberrypi ~ $ sudo service sshd status
● ssh.service - OpenBSD Secure Shell server
 Loaded: loaded (/lib/systemd/system/ssh.service; enabled)
 Active: active (running) since Thu 2015-10-08 12:17:06 UTC; 4 days ago
 Main PID: 506 (sshd)
 CGroup: /system.slice/ssh.service
 └─506 /usr/sbin/sshd -D

If everything is working, you should see the text active (running) in the result. Once we know that an ssh server is running, we can check our ip address with the ifconfig command. The output should look something like this:

pi@raspberrypi ~ $ ifconfig
eth0      Link encap:Ethernet  HWaddr b8:27:eb:b9:49:cd  
          inet addr:192.168.0.109  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:5150 errors:0 dropped:51 overruns:0 frame:0
          TX packets:565 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:552488 (539.5 KiB)  TX bytes:60766 (59.3 KiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:1104 (1.0 KiB)  TX bytes:1104 (1.0 KiB)

If your Pi is connected to a LAN cable, you’ll want to look at the eth0 section. If it’s connected to WiFi, look for a wlan0 section. Both sections should have an inet addr field whose value starts with a 192.168.x.x address. In my case, it’s 192.168.0.109. From a terminal on my computer, I can connect with:

jfritz@IDEAPAD-UBUNTU:~$ ssh pi@192.168.0.109

When prompted to accept the Pi’s RSA key, I do, and when prompted for a password, I enter the default password raspberry. If you intend to leave the Pi connected to your network for long periods of time, you should change this password or add key-based authentication to the system.

If you have problems getting connected, check out the official instructions on the Raspberry Pi website.

Installing ROS on the Pi

As of this writing, the most recent version of ROS is Indigo, released in July of 2014. To get it running on the Pi, you’ll want to follow the official ROSberryPi installation instructions on the ROS website.

While following these instructions, I had a few false starts. It’s important to read the instructions carefully, as they’re fairly generic, and can be used to install different configurations of ROS on different versions of Raspbian. I found that the instructions for the ros_conn configuration worked best on Raspbian’s Wheezy release.

The  trickiest part of the instructions is section 2.2 Resolve Dependencies. It took me a couple of reads to realize that if you’re installing ROS Indigo’s ros_conn configuration on Raspbian Wheezy, you only need to compile two packages from source: libconsole-bridge-dev and liblz4-dev. Installing any other packages at this step just costs you time, and may introduce problems down the road.

I also found that the install process went much smoother when the Pi was connected to a LAN rather than WiFi. The WiFi signal in my house is relatively weak, and the Realtek #814B is really cheap, so downloading a lot of files while maintaining an SSH connection is a big ask.

Once the installation is complete, open up your ~/.bashrc file, and add two lines to the end:

# export ROS environment variables
source /opt/ros/indigo/setup.bash

This will make sure that the appropriate environment variables are set to interact with ROS on every startup. You can check that it worked by rebooting your Pi and running

pi@raspberrypi ~ $ printenv | grep ROS
ROS_ROOT=/opt/ros/indigo/share/ros
ROS_PACKAGE_PATH=/opt/ros/indigo/share:/opt/ros/indigo/stacks
ROS_MASTER_URI=http://localhost:11311
ROS_DISTRO=indigo
ROS_ETC_DIR=/opt/ros/indigo/etc/ros

If you see all of the ROS_* environment variables print out, then everything is set up and ready to go. Now it’s time to start on some tutorials.

Eventually, I want to get the Raspberry Pi communicating with the Arduino, and use the latter as a sensor platform and motor controller for some kind of a robot. For now, I need to find my way around ROS.

This article originally appeared at jonathanfritz.ca




On my Laptop, I am running Linux Mint 12.
On my home media server, I am running Ubuntu 12.04
Check out my profile for more information.

CoreGTK 3.10.2 Released!

February 19th, 2016 No comments

The next version of CoreGTK, version 3.10.2, has been tagged for release today.

Highlights for this release:

  • This is a bug fix release.
  • Corrected issue with compiling CoreGTK on OS X.

CoreGTK is an Objective-C language binding for the GTK+ widget toolkit. Like other “core” Objective-C libraries, CoreGTK is designed to be a thin wrapper. CoreGTK is free software, licensed under the GNU LGPL.

You can find more information about the project here and the release itself here.

This post originally appeared on my personal website here.




I am currently running a variety of distributions, primarily Linux Mint 17.
Previously I was running KDE 4.3.3 on top of Fedora 11 (for the first experiment) and KDE 4.6.5 on top of Gentoo (for the second experiment).

Automating Let’s Encrypt certificates on nginx

February 19th, 2016 No comments

Let’s Encrypt is a new Certificate Authority that provides free SSL certificates. It is intended to be automated, so that certificates are renewed automatically. We’re using Let’s Encrypt certificates for our set of free Calculus practice problems. Our front end is currently served by an Ubuntu server running nginx, and here’s how we have it scripted on that machine. In a future post, I’ll describe how it’s automated on our Docker setup with HAProxy.

First of all, we’re using acme-tiny instead of the official Let’s Encrypt client, since it’s much smaller and, IMHO, easier to use. It takes a bit more to set up, but works well once it’s set up.

We installed acme-tiny in /opt/acme-tiny, and created a new letsencrypt user. The letsencrypt user is only used to run the acme-tiny client with reduced priviledge. In theory, you could run the entire renewal process with a reduced priviledge user, but the rest of the process is just basic shell commands, and my paranoia level is not that high.

We created an /opt/acme-tiny/challenge directory, owned by the letsencrypt user, and we created /etc/acme-tiny with the following contents:

  • account.key: the account key created in step 1 from the acme-tiny README. This file should be readable only by the letsencrypt user.
  • certs: a directory containing a subdirectory for each certificate that we want. Each subdirectory should have a domain.csr file, which is the certificate signing request created in step 2 from the acme-tiny README. The certs directory should be publicly readable, and the subdirectories should be writable by the user that the cron job will run as (which does not have to be the letsencrypt user).
  • private: a directory containing a subdirectory for each certificate that we want, like we had with the certs directory. Each subdirectory has a file named privkey.key, which will be the private key associated with the certificate. To coincide with the common setup on Debian systems, the private directory should be readable only by the ssl-cert group.

Instead of creating the CSR files as described in the acme-tiny README, I created a script called gen_csr.sh:

#!/bin/bash
openssl req -new -sha256 -key /etc/acme-tiny/private/"$1"/privkey.pem -subj "/" -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:") <(cat /etc/acme-tiny/certs/"$1"/domains | sed "s/\\s*,\\s*/,DNS:/g")) > /etc/acme-tiny/certs/"$1"/domain.csr

The script is invoked as gen_scr.sh <name>. It reads a file named /etc/acme-tiny/certs/<name>/domains, which is a text file containing a comma-separated list of domains, and it writes the /etc/acme-tiny/certs/<name>/domain.csr file.

Now we need to configure nginx to serve the challenge files. We created a /etc/nginx/snippets/acme-tiny.conf file with the following contents:

location /.well-known/acme-challenge/ {
    auth_basic off;
    alias /opt/acme-tiny/challenge/;
}

(The “auth_basic off;” line is needed because some of our virtual hosts on that server use basic HTTP authentication.) We then modify the sites in /etc/nginx/sites-enabled that we want to use Let’s Encrypt certificates to include the line “include snippets/acme-tiny.conf;“.

After this is set up, we created a /usr/local/sbin/letsencrypt-renew script that will be used to request a new certificate:

#!/bin/sh
set +e

# only renew if certificate will expire within 20 days (=1728000 seconds)
openssl x509 -checkend 1728000 -in /etc/acme-tiny/certs/"$1"/cert.pem && exit 255

set -e
DATE=`date +%FT%R`
su letsencrypt -s /bin/sh -c "python /opt/acme-tiny/acme_tiny.py --account-key /etc/acme-tiny/account.key --csr /etc/acme-tiny/certs/\"$1\"/domain.csr --acme-dir /opt/acme-tiny/challenge/" > /etc/acme-tiny/certs/"$1"/cert-"$DATE".pem
ln -sf cert-"$DATE".pem /etc/acme-tiny/certs/"$1"/cert.pem
wget https://letsencrypt.org/certs/lets-encrypt-x1-cross-signed.pem -O /etc/acme-tiny/lets-encrypt-x1-cross-signed.pem
cat /etc/acme-tiny/certs/"$1"/cert-"$DATE".pem /etc/acme-tiny/lets-encrypt-x1-cross-signed.pem > /etc/acme-tiny/certs/"$1"/fullchain-"$DATE".pem
ln -sf fullchain-"$DATE".pem /etc/acme-tiny/certs/"$1"/fullchain.pem

The script will only request a new certificate if the current certificate will expire within 20 days. The certificates are stored in /etc/acme-tiny/certs/<name>/cert-<date>.pem (symlinked to /etc/acme-tiny/certs/<name>/cert.pem). The full chain (including the intermediate CA certificate) is stored in /etc/acme-tiny/certs/<name>/fullchain-<date>.pem (symlinked to /etc/acme-tiny/certs/<name>/fullchain.pem).

As-is, the script must be run as root, since it does a su to the letsencrypt user. It should be trivial to modify it to use sudo instead, so that it can be run by any user that has the appropriate permissions on /etc/acme-tiny.

the letsencrypt-renew script is run by another script that will restart the necessary servers if needed. For us, the script looks like this:

#!/bin/sh

letsencrypt-renew sbscalculus.com

RV=$?

set -e

if [ $RV -eq 255 ] ; then
  # renewal not needed
  exit 0
elif [ $RV -eq 0 ] ; then
  # restart servers
  service nginx reload;
else
  exit $RV;
fi

This is then called by a cron script of the form chronic /usr/local/sbin/letsencrypt-renew-and-restart. Chronic is a script from the moreutils package that runs a command and only passes through its output if it fails. Since the renewal script checks whether the certificate will expire, we run the cron task daily.

Of course, once you have the certificate, you want to tell nginx to use it. We have another file in /etc/nginx/snippets that, aside from setting various SSL parameters, includes

ssl_certificate /etc/acme-tiny/certs/sbscalculus.com/fullchain.pem;
ssl_certificate_key /etc/acme-tiny/private/sbscalculus.com/privkey.pem;

This is the setup we use for one of our server. I tried to make it fairly general, and it should be fairly easy to modify for other setups.

 

This article was originally published at Hubert’s personal website here.

Categories: Hubert C, Linux, Ubuntu Tags: ,

Enter the Void! First impressions of Void Linux

January 23rd, 2016 1 comment
Void Linux

Void Linux

While Gentoo is a great way to spin your own flavour of Linux, after a year I’ve found that recompiling packages every time you do an update becomes a bit of a drag. With that in mind I decided to look around for an alternative distribution, and while nothing is 100% perfect I have to say I really am very happy with Void Linux. There are a number of “live” iso images which will happily boot from a USB stick, I only looked at two of the images Cinnamon and Xfce, while Cinnamon was all very pretty and all that, I couldn’t get the audio volume widget to show itself and besides I didn’t see any real advantage. I’ve long been a fan of Xfce basically because of what it doesn’t try to do, you don’t get the kitchen sink (thankfully) but what you do get works solidly.

Now its entirely possible that I missed something obvious with the void_installer script but it has two distinct behaviours depending on what installation source you choose. If you choose to install from the internet what you get is a bare minimum of packages (command line only) and you’ll be left with a fair bit of configuration to do for yourself – this isn’t always a bad thing if for example you have some specific use maybe an embedded kiosk for example. For more usual desktop use, its better to choose the installation media itself as the source, this basically copies and configures the “live” image onto your machine. I did find that after an update I had to manually delete the old kernel, but once I did that and a few more of the usual chores one normally expects when installing a new system – (eventually after correctly using the installer!) I found myself in possession of a really nice system.

Void is a sleek system, obviously well engineered and the best thing has to be the package manager – xbps comprises in a small suite of interrelated console applications, which do just one narrow function each, for example given the choice of xbps-install, xbps-query, xbps-remove etc you can make a good guess at what they do. As you’d expect each xbps app if run without parameters gives you a quick run down of commands and parameters. One thing I did notice with xbps is its fast, and no mistake! There is a graphical package manager too (octoxbps) which is both familiar but refreshingly slightly different (and not just for the sake of it either) I didn’t manage to find an update reminder but the xbps tools are easy to work with and I was able to make a simple script to do a dry run update (so nothing’s changed) from this I can infer the number of updates that need to be done.

#!/bin/bash
n=`xbps-install -Snu | wc -l`
if [ $n -gt 0 ]
 then
 if [ $n -eq 1 ]
 then
 m="there is a system update to do"
 else
 m="there are $n system updates to do"
 fi
 zenity --info --text="$m"
 fi

I auto run this when the desktop environment starts, keeping package information synced and warning me of updates – this will be most useful when installed on machines that I maintain for others who let us say just need a gentle reminder about updates…

Of course everything was going far too well (spoiling my fun! just working like that) the only one big issue I had was with steam, but the Void forum soon came to my aid with a work around, a particular version of the Xorg driver for Intel gpu’s was causing some kind of networking issue (of all things) I won’t bore you with the details but suffice to say its working with a “little” persuasion!

I did notice pulse audio is installed by default, which seemed a little odd as I’m not sure it provides a great deal for the extra overhead, uninstalling pulse audio doesn’t break anything and getting Alsa going is just a case of enabling the daemon in the alsa-utils package and adding the usual Alsa configuration (~/.asoundrc)

pcm.!default {
 type plug
 slave {
 pcm "hw:1,0"
 }
 }
 ctl.!default {
 type hw
 card 1
 }

I’ve since found a better way to configure ALSA – a quote from their website

Neither .asoundrc or /etc/asound.conf is normally required. You should be able to play and record sound without either (assuming your mic and speakers are hooked up properly). If your system won’t work without one, and you are running the most current version of ALSA, you probably should file a bug report.

That said it did assume the HDMI output was the default so an even simpler config for the kernel module itself allowed me to disable HDMI sound which I have no use for…

/etc/modprobe.d/alsa-base.conf 

options snd_hda_intel enable=1 index=0
options snd_hda_intel enable=0 index=1

Your system might differ but its not really a problem, its just nice there are no enforced and/or needless package dependencies like there are with some other distributions.

Further testing centred on Java development, I knew if I was going to hit any major show stoppers that Jgles2 (with its multiple build systems) would likely show up issues. Not unusually for Void, Ant’s package was bang up to date (wish I could say the same of Gentoo – as at the time of writing Ant is languishing at version 1.9.2 which isn’t enough to compile Lwjgl….) installing g++, make and pkg-config had the complete build system for Jgles2 working as I’d expect.

While its still early days, and its not impossible I could find some wrinkles – all in all so far Void seems a positive experience and well worth considering.

Introducing Chris C, our occasional guest writer.
This article was originally published at his personal website here.

Categories: Chris C, Linux Tags:

KWLUG: Mageia Linux, Tax Software (2016-01)

January 12th, 2016 No comments

This is a podcast presentation from the Kitchener Waterloo Linux Users Group on the topic of Mageia Linux, Tax Software published on January 5th 2016. You can find the original Kitchener Waterloo Linux Users Group post here.

Read more…




I am currently running a variety of distributions, primarily Linux Mint 17.
Previously I was running KDE 4.3.3 on top of Fedora 11 (for the first experiment) and KDE 4.6.5 on top of Gentoo (for the second experiment).
Categories: Linux, Podcast, Tyler B Tags: ,

KWLUG: GNU Social (2015-12)

January 12th, 2016 No comments

This is a podcast presentation from the Kitchener Waterloo Linux Users Group on the topic of GNU Social published on December 8th 2015. You can find the original Kitchener Waterloo Linux Users Group post here.

Read more…




I am currently running a variety of distributions, primarily Linux Mint 17.
Previously I was running KDE 4.3.3 on top of Fedora 11 (for the first experiment) and KDE 4.6.5 on top of Gentoo (for the second experiment).
Categories: Linux, Podcast, Tyler B Tags: ,

Linux alternatives: Mp3tag → puddletag

November 28th, 2015 No comments

Way back when I first made my full-time switch to Linux I made a post about an alternative to the excellent Mp3tag software on Windows. At the time I suggested a program called EasyTAG and while that is still a good program I’ve recently come across one that I think I may actually like more: puddletag.

A screenshot of puddletag from their website

A screenshot of puddletag from their website

While it is very similar to EasyTAG I find puddletag’s layout a bit easier to navigate and use.

This post originally appeared on my personal website here.




I am currently running a variety of distributions, primarily Linux Mint 17.
Previously I was running KDE 4.3.3 on top of Fedora 11 (for the first experiment) and KDE 4.6.5 on top of Gentoo (for the second experiment).

Big distributions, little RAM 9

November 28th, 2015 2 comments

It’s been a while but once again here is the latest instalment of the series of posts where I install the major, full desktop, distributions into a limited hardware machine and report on how they perform. Once again, and like before, I’ve decided to re-run my previous tests this time using the following distributions:

  • Debian 8.2 (Cinnamon)
  • Debian 8.2 (GNOME)
  • Debian 8.2 (KDE)
  • Debian 8.2 (MATE)
  • Debian 8.2 (Xfce)
  • Elementary OS 0.3.1 (Freya)
  • Kubuntu 15.10 (KDE)
  • Linux Mint 17.2 (Cinnamon)
  • Linux Mint 17.2 (MATE)
  • Linux Mint 17.2 (Xfce)
  • Mageia 5 (GNOME)
  • Mageia 5 (KDE)
  • Ubuntu 15.10 (Unity)
  • Xubuntu 15.10 (Xfce)

I also attempted to try and install Fedora 23, Linux Mint 17.2 (KDE) and OpenSUSE 42.1 but none of them were able to complete installation.

All of the tests were done within VirtualBox on ‘machines’ with the following specifications:

  • Total RAM: 512MB
  • Hard drive: 10GB
  • CPU type: x86 with PAE/NX
  • Graphics: 3D Acceleration enabled

The tests were all done using VirtualBox 5, and I did not install VirtualBox tools (although some distributions may have shipped with them). I also left the screen resolution at the default (whatever the distribution chose) and accepted the installation defaults. All tests were run prior to December 2015 so your results may not be identical.

Results

Just as before I have compiled a series of bar graphs to show you how each installation stacks up against one another. Measurements were taken using the free -m command for memory and the df -h command for disk usage.

Like before I have provided the results file as a download so you can see exactly what the numbers were or create your own custom comparisons (see below for link).

Things to know before looking at the graphs

First off if your distribution of choice didn’t appear in the list above its probably not reasonably possible to be installed (i.e. I don’t have hours to compile Gentoo) or I didn’t feel it was mainstream enough (pretty much anything with LXDE). As always feel free to run your own tests and link them in the comments for everyone to see.

Quick Info

  • Out of the Cinnamon desktops tested Debian 8.2 had the lowest memory footprint
  • Out of the GNOME desktops tested Mageia 5 had the lowest memory footprint
  • Out of the KDE desktops tested Mageia 5 had the lowest memory footprint
  • Out of the Xfce desktops tested Debian 8.2 had the lowest memory footprint
  • Out of the MATE desktops tested Debian 8.2 had the lowest memory footprint
  • Elementary OS 0.3.1 had the highest memory footprint of those tested
  • Debian 8.2 Xfce and MATE tied for the lowest memory footprint of those tested
  • Debian 8.2 Xfce had the lowest install size of those tested
  • Kubuntu 15.10 had the largest install size of those tested
  • Elementary OS 0.3.1 had the lowest change after updates (+2MiB)
  • Mageia 5 KDE had the largest change after updates (-265MiB)

First boot memory (RAM) usage

This test was measured on the first startup after finishing a fresh install.

big_distro_little_ram_9_first_boot_memory_usageMemory (RAM) usage after updates

This test was performed after all updates were installed and a reboot was performed.

big_distro_little_ram_9_memory_usage_after_updatesMemory (RAM) usage change after updates

The net growth or decline in RAM usage after applying all of the updates.

big_distro_little_ram_9_memory_usage_change_after_updatesInstall size after updates

The hard drive space used by the distribution after applying all of the updates.

big_distro_little_ram_9_install_sizeConclusion

Once again I will leave the conclusions to you. Source data provided below.

Source Data




I am currently running a variety of distributions, primarily Linux Mint 17.
Previously I was running KDE 4.3.3 on top of Fedora 11 (for the first experiment) and KDE 4.6.5 on top of Gentoo (for the second experiment).

Distro hopping: feeling good with my time on LXLE

November 23rd, 2015 No comments

Well the time has come to officially switch off from LXLE. This time around however I find myself in a weird spot. I’ve honestly struggled with LXLE; not in using the distribution itself but rather coming up with things to write about it. That isn’t to say that LXLE is bad by any stretch of the imagination, in fact it is quite good, it’s just that once you get used to the light weight desktop environment (DE) there is a perfectly capable “heavy weight” distribution underneath. What I mean by this is that once you get used to the DE and it fades into the background you’re left with a perfectly functional distribution that could just as easily have been Ubuntu or Linux Mint or Fedora or {insert your favourite one here}.

Due to this strength I didn’t find myself struggling to make things work or figure out new ways to accomplish the things I needed to do… things were pretty much where I expected them to be… and that’s a great thing! It means that if you want to run a distribution that will be somewhat lighter on your system but you don’t want to scrimp on the applications you need to get work done then LXLE may just be for you.

The desktop

The desktop

Pros:

  • One of the few distributions that uses the light weight LXDE environment
  • Very low system resources (my machine took less than 400MiB of RAM after logging into the desktop!)
  • Just because it is a light weight distribution doesn’t mean it gives you less featured alternative applications
  • Boring… but in a good way! The distribution gets out of your way and lets you get work done!

Cons:

  • Still a couple of little bugs that seem like obvious things that would be caught if it had a larger user base
  • Ships with a load of applications, the majority of which most people probably won’t use day-to-day (maybe they could save some space instead?)
  • Boring… other than the desktop environment there isn’t anything overly unique to this distribution. Seems like you could just install LXDE on top of Ubuntu and get the same thing.

Other:

  • How awesome is the desktop background changer button right in the tool bar? I mean at first I thought it was a ridiculous waste of space but now I’m addicted to changing my desktop wallpaper with the push of a button.

Be sure to check back here soon to find out where I land next!

This post is part of a series:




I am currently running a variety of distributions, primarily Linux Mint 17.
Previously I was running KDE 4.3.3 on top of Fedora 11 (for the first experiment) and KDE 4.6.5 on top of Gentoo (for the second experiment).
Categories: LXLE, Tyler B Tags: ,

Distro hopping: adding a podcast in Guayadeque on LXLE

November 15th, 2015 No comments

I have to admit that I hadn’t even heard of Guayadeque until starting this little distro hopping adventure but since then I’ve found it to be the default music player in more than one distribution. As such I’ve decided to try and use it to see if it will work better for me instead of the usual alternatives.

Seeing as I’m a big fan of podcasts I’ve decided to see how Guayadeque handles the process of adding and listening to my feeds.

Start Guayadeque and click the Podcasts tab

Step 1

Step 1

Right click under the Channels column and click New Channel

You can add feeds directly from the podcast directory or from feed URLs

You can add feeds directly from the podcast directory or from feed URLs

If for some reason you can’t find your podcast in their existing directory you can simply find the podcast RSS feed and plug it into the Url text box instead.

For example let’s say I wanted to add the feed for Listener Feedback podcast. Unfortunately it isn’t already listed in the built-in directory but there are a few handy feeds that I found on the website here (there is even an Ogg Vorbis feed for higher quality). Once pasted in Guayadeque was able to find the podcast details right away:

Some handy settings are available

Some handy settings are available

Download and play

A short download later and the podcast is ready to be played!

Playing away

Playing away

So all told it’s a relatively painless to add a podcast to Guayadeque. My one issues with the user interface are that it feels a bit dated and seems to require a lot of right-clicking and context menus which may not be immediately obvious for some users. That said they’re very minor complaints and it is still a very functional application.

This post is part of a series:




I am currently running a variety of distributions, primarily Linux Mint 17.
Previously I was running KDE 4.3.3 on top of Fedora 11 (for the first experiment) and KDE 4.6.5 on top of Gentoo (for the second experiment).

Distro hopping: slimming down with LXLE

November 8th, 2015 1 comment

Now that my time with BSD has come to an end I thought I should jump back into Linux via a distribution I had never even heard of before (just to keep things interesting!). DistroWatch is an excellent source for finding different, unique and of course obscure distributions but I was surprised to find one in the top 10 that I had never even heard of before: LXLE.

LXLE on the DistroWatch top 10

LXLE on the DistroWatch top 10

So what exactly is LXLE? Well according to their website:

LXLE is based on Lubuntu which is an Ubuntu OS using the LXDE desktop environment. It is designed to be a drop-in and go OS, primarily for aging computers. Its intention is to be able to install it on any computer and be relatively done after install. At times removing unwanted programs or features is easier than configuring for a day. Our distro follows the same LTS schedule as Ubuntu. In short, LXLE is an eclectic respin of Lubuntu with its own user support.

After a quick install I am now running on LXLE!

The desktop

The desktop

Let’s take a quick walk through of what comes with this light weight distribution.

To browse your files it comes with the slim PCManFM:

PCManFM

PCManFM

Unfortunately it is also where I ran into my first issue with the distribution. The default user name in the installer was “qwerty” but somehow this survived, even though I replaced it with my own name, in the quick Places links along the left-hand side of the window. They still pointed to non-existent locations based on this default user name.

That's... not right...

That’s… not right…

Seamonkey suite is used for most basic Internet functionality including web browsing, e-mail, FTP, IRC, etc.

Seamonkey

Seamonkey web browser

Other interesting inclusions are anti-virus scanner ClamTk, password manager KeePassX, open source BitTorrent Sync alternative Syncthing, instant messenger Pidgin, Tox client uTox, music editor Audacity, music player Guayadeque, a load of games and many, many more utilities.

ClamTk, for all your virus scanning needs

ClamTk, for all your virus scanning needs

For a distribution that prides itself on being light weight it sure does ship with a lot of software! Like the others I’ll be playing around with LXLE over the next couple of days and post my thoughts and experiences here.

This post is part of a series:




I am currently running a variety of distributions, primarily Linux Mint 17.
Previously I was running KDE 4.3.3 on top of Fedora 11 (for the first experiment) and KDE 4.6.5 on top of Gentoo (for the second experiment).
Categories: LXLE, Tyler B Tags: ,

KWLUG: Sound in Linux (2015-11)

November 5th, 2015 No comments

This is a podcast presentation from the Kitchener Waterloo Linux Users Group on the topic of Sound in Linux published on November 5th 2015. You can find the original Kitchener Waterloo Linux Users Group post here.

Read more…




I am currently running a variety of distributions, primarily Linux Mint 17.
Previously I was running KDE 4.3.3 on top of Fedora 11 (for the first experiment) and KDE 4.6.5 on top of Gentoo (for the second experiment).
Categories: Linux, Podcast, Tyler B Tags: , ,

KWLUG: File Synchronization (2015-10)

October 10th, 2015 No comments

This is a podcast presentation from the Kitchener Waterloo Linux Users Group on the topic of File Synchronization published on October 5th 2015. You can find the original Kitchener Waterloo Linux Users Group post here.

Read more…




I am currently running a variety of distributions, primarily Linux Mint 17.
Previously I was running KDE 4.3.3 on top of Fedora 11 (for the first experiment) and KDE 4.6.5 on top of Gentoo (for the second experiment).

Distro hopping: curtains for Manjaro Linux

September 29th, 2015 1 comment

The time has come to wrap things up with Manjaro and hop on to the next distribution to try out. So here are some final thoughts on my short time with Manjaro Linux.

Manjaro has a very nice theme

Manjaro has a very nice theme

Pros:

Cons:

  • …at times also a completely bizzare collection of default software. Qt4 Designer? Sensor Viewer? These seem like things that could probably just be added by users who want them after the fact instead of being default software.
  • Just like what Chakra did for Gentoo, I’m not exactly sure where Manjaro wants to sit. Is it a polished distribution for new/average users? Is it a power users dream come true? Neither is really quite right…

Other:

  • Why isn’t Manjaro a more popular distribution? It seems like it should be.

manjaro_welcome

Come back soon to find out what’s next!

This post is part of a series:




I am currently running a variety of distributions, primarily Linux Mint 17.
Previously I was running KDE 4.3.3 on top of Fedora 11 (for the first experiment) and KDE 4.6.5 on top of Gentoo (for the second experiment).
Categories: Manjaro Linux, Tyler B Tags: