Archive

Author Archive

How to mount a Windows share on startup

April 28th, 2014 2 comments

I recently invested in a NAS device to add a little bit of redundancy to my personal files. With this particular NAS the most convenient way to use the files it stores is via the Windows share protocol (also known a SMB or CIFS). Linux has supported these protocols for a while now so that’s great but I wanted it to automatically map the shared directory on the NAS to a directory on my Linux computer on startup. Thankfully there is a very easy way to do just that.

1) First install cifs-utils

sudo apt-get install cifs-utils

2) Next edit the fstab file and add the share(s)

To do this you’ll need to add a new line to the end of the file. You can easily open the file using nano in the terminal by running the command:

sudo nano /etc/fstab

Then use the arrow keys to scroll all the way to the bottom and add the share in the following format:

//<path to server>/<share name>     <path to local directory>     cifs     guest,uid=<user id to mount files as>,iocharset=utf8     0     0

Breaking it down a little bit:

  • <path to server>: This is the network name or IP address of the computer hosting the share (in my case the NAS). For example it could be something like “192.168.1.1” or something like “MyNas”
  • <share name>: This is the name of the share on that computer. For example I set up my NAS to share different directories one of which was called “Files”
  • <path to local directory>: This is where you want the remote files to appear locally. For example if you want them to appear in a folder under /media you could do something like “/media/NAS”. Just make sure that the directory exists (create it if you need to).
  • <user id to mount files as>: This defines the permissions to give the files. On Ubuntu the first user you create is usually give uid 1000 so you could put “1000” here. To find out the uid of any random user use the command “id <user>” without quotes.

So for example my added line in fstab was

//192.168.3.25/Files     /media/NAS     cifs     guest,uid=1000,iocharset=utf8     0     0

Then save the file “Ctrl+O” and then Enter in nano.

3) Mount the remote share

Run this command to test the share:

sudo mount -a

If that works you should see the files appear in your local directory path. When you restart the computer it will also attempt to connect to the share and place the files in that location as well. Keep in mind that anything you do to the files there also changes them on the share!




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: , , , , ,

Ubuntu 14.04 VNC woes? Try this!

April 28th, 2014 No comments

If, like me, you’ve recently upgraded to Ubuntu 14.04 only to find out that for whatever reason you can no longer VNC to that machine anymore (either from Windows or even an existing Linux install) have no fear because I’ve got the fix for you!

Simply open up a terminal and run the following line:

gsettings set org.gnome.Vino require-encryption false

Obviously if you use VNC encryption you may not want to do this but if you’re like me and just use VNC on the local network it should be safe enough to disable.




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).

Extend the life of your SSD on linux

February 9th, 2014 2 comments

This past year I purchased a laptop that came with two drives, a small 24GB SSD and a larger 1TB HDD. My configuration has placed the root filesystem (i.e. /) on the SSD and my home directory (i.e. /home) on the HDD so that I benefit from very fast system booting and application loading but still have loads of space for my personal files. The only downside to this configuration is that linux is sometimes not the best at ensuring your SSD lives a long life.

Unlike HDDs, SSDs have a finite number of write operations before they are guaranteed to fail (although you could argue HDDs aren’t all that great either…). Quite a few linux distributions have not yet been updated to detect and configure SSDs in such a way as to extend their life. Luckily for us it isn’t all that difficult to make the changes ourselves.

Change #1 – noatime

The first change that I do is to configure my system so that it no longer updates each files access time on the SSD partition. By default Linux records information about when files were created and last modified as well as when it was last accessed. There is a cost associated with recording the last access time and including this option can not only significantly reduce the number of writes to the drive but also give you a slight performance improvement as well. Note that if you care about access times (for example if you like to perform filesystem audits or something like that) then obviously disabling this may not be an option for you.

Open /etc/fstab as root. For example I used nano so I ran:

sudo nano /etc/fstab

Find the SSD partition(s) (remember mine is just the root, /, partition) and add noatime to the mounting options:

UUID=<some hex string> /               ext4    noatime,errors=remount-ro

Change #2 – discard

UPDATE: Starting with 14.04 you no longer need to add discard to your fstab file. It is now handled automatically for you through a different system mechanism.

TRIM is a technology that allows a filesystem to immediately notify the SSD when a file is deleted so that it can more efficiently manage the underlying storage and improve the lifespan of the drive. Not all filesystems support TRIM but if you are like most people and use ext4 then you can safely enable this feature. Note that some people have actually had drastic write performance decreases when enabling this option but personally I’d rather have that than a dead drive.

To enable TRIM support start by again opening /etc/fstab as root and find the SSD partition(s). This time add discard to the mounting options:

UUID=<some hex string> /               ext4    noatime,errors=remount-ro,discard

Change #3 – tmpfs

If you have enough RAM you can also dedicate some of it to mounting specific partitions via tmpfs. Tmpfs essentially makes a fake hard drive, known as a RAM disk, that exists only in your computer’s RAM memory while it is running. You could use this to store commonly written to temporary filesystems like /tmp or log file locations such as /var/logs.

This has a number of consequences. For one anything that gets written to tmpfs will not be there the second you restart or turn the computer off – it never gets written back to a real hard drive. This means that while you can save your SSD all of those log file writes you also won’t be able to debug a problem using those log files on a computer crash or something of the like. Also being a RAM disk means that it will slowly(?) eat up your RAM growing larger and larger the more you write to it between restarts. There are options for putting limits on how large a tmpfs partition can grow but I’ll leave you to search for those.

To set this up open /etc/fstab as root. This time add new tmpfs lines using the following format:

tmpfs   /tmp    tmpfs   defaults  0       0

You can lock it down even more by adding some additional options like noexec (disallows execution of binaries on the filesystem) and nosuid (block the operation of suid, and sgid bits). Some other locations you may consider adding are /var/log, /var/cache/apt etc. Please read up on each of these before applying them as YMMV.

Categories: Hardware, Tyler B Tags: , , , , ,

Change the default sort order in Nautilus

February 9th, 2014 1 comment

The default sort order in Nautilus has been changed to sorting alphabetically by name and the option to change this seems to be broken. For example I prefer my files to be sorted by type so I ran

dconf-editor

and browsed to org/gnome/nautilus/preferences. From there you should be able to change the value by using the drop down:

 

Seems easy enough

Seems easy enough

Unfortunately the only option available is modification time. Once you change it to that you can’t even go back to name. This also appears to be a problem when trying to set the value using the command line interface like this:

dconf write /org/gnome/nautilus/preferences/default-sort-order type

I received an “error: 0-4:unknown keyword” message when I tried to run that.

Thanks to the folks over on the Ask Ubuntu forum I was finally able to get it to change by issuing this command instead:

gsettings set org.gnome.nautilus.preferences default-sort-order type

where type could be swapped out for whatever you prefer it to be ordered by.

Great Success!

Great Success!

CoreGTK

January 28th, 2014 2 comments

A while back I made it my goal to put together an open source project as my way of contributing back to the community. Well fast forward a couple of months and my hobby project is finally ready to be shown the light of day. I give you… CoreGTK

CoreGTK is an Objective-C binding for the GTK+ library which wraps all objects descending from GtkWidget (plus a few others here and there). Like other “core” Objective-C libraries it is designed to be a very thin wrapper, so that anyone familiar with the C version of GTK+ should be able to pick it up easily.

However the real goal of CoreGTK is not to replace the C implementation for every day use but instead to allow developers to more easily code GTK+ interfaces using Objective-C. This could be especially useful if a developer already has a program, say one they are developing for the Mac, and they want to port it to Linux or Windows. With a little bit of MVC a savvy developer would only need to re-write the GUI portion of their application in CoreGTK.

So what does a CoreGTK application look like? Pretty much like a normal Objective-C program:

/*
 * Objective-C imports
 */
#import <Foundation/Foundation.h>
#import "CGTK.h"
#import "CGTKButton.h"
#import "CGTKSignalConnector.h"
#import "CGTKWindow.h"

/*
 * C imports
 */
#import <gtk/gtk.h>

@interface HelloWorld : NSObject
/* This is a callback function. The data arguments are ignored
 * in this example. More callbacks below. */
+(void)hello;

/* Another callback */
+(void)destroy;
@end

@implementation HelloWorld
int main(int argc, char *argv[])
{
    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];

    /* We could use also CGTKWidget here instead */
    CGTKWindow *window;
    CGTKButton *button;

    /* This is called in all GTK applications. Arguments are parsed
    * from the command line and are returned to the application. */
    [CGTK autoInitWithArgc:argc andArgv:argv];

    /* Create a new window */
    window = [[CGTKWindow alloc] initWithGtkWindowType:GTK_WINDOW_TOPLEVEL];

    /* Here we connect the "destroy" event to a signal handler in 
     * the HelloWorld class */
    [CGTKSignalConnector connectGpointer:[window WIDGET] 
        withSignal:@"destroy" toTarget:[HelloWorld class] 
        withSelector:@selector(destroy) andData:NULL];

    /* Sets the border width of the window */
    [window setBorderWidth: [NSNumber numberWithInt:10]];

    /* Creates a new button with the label "Hello World" */
    button = [[CGTKButton alloc] initWithLabel:@"Hello World"];

    /* When the button receives the "clicked" signal, it will call the
     * function hello() in the HelloWorld class (below) */
    [CGTKSignalConnector connectGpointer:[button WIDGET] 
        withSignal:@"clicked" toTarget:[HelloWorld class] 
        withSelector:@selector(hello) andData:NULL];

    /* This packs the button into the window (a gtk container) */
    [window add:button];

    /* The final step is to display this newly created widget */
    [button show];

    /* and the window */
    [window show];

    /* All GTK applications must have a [CGTK main] call. Control ends here
     * and waits for an event to occur (like a key press or
     * mouse event). */
    [CGTK main];

    [pool release];

    return 0;
}

+(void)hello
{
    NSLog(@"Hello World");
}

+(void)destroy
{
    [CGTK mainQuit];
}
@end
Hello World in action

Hello World in action

And because Objective-C is completely compatible with regular old C code there is nothing stopping you from simply extracting the GTK+ objects and using them like normal.

// Use it as an Objective-C CoreGTK object!
CGTKWindow *cWindow = [[CGTKWindow alloc] 
    initWithGtkWindowType:GTK_WINDOW_TOPLEVEL];

// Or as a C GTK+ window!
GtkWindow *gWindow = [cWindow WINDOW];

// Or even as a C GtkWidget!
GtkWidget *gWidget = [cWindow WIDGET];

// This...
[cWindow show];

// ...is the same as this:
gtk_widget_show([cWindow WIDGET]);

You can even use a UI builder like GLADE, import the XML and wire up the signals to Objective-C instance and class methods.

CGTKBuilder *builder = [[CGTKBuilder alloc] init];
if(![builder addFromFile:@"test.glade"])
{
    NSLog(@"Error loading GUI file");
    return 1;
}

[CGTKBuilder setDebug:YES];

NSDictionary *dic = [[NSDictionary alloc] initWithObjectsAndKeys:
                 [CGTKCallbackData withObject:[CGTK class] 
                     andSEL:@selector(mainQuit)], @"endMainLoop",
                 [CGTKCallbackData withObject:[HelloWorld class] 
                     andSEL:@selector(hello)], @"on_button2_clicked",
                 [CGTKCallbackData withObject:[HelloWorld class] 
                     andSEL:@selector(hello)], @"on_button1_activate",
                 nil];

[builder connectSignalsToObjects:dic];

CGTKWidget *w = [builder getWidgetWithName:@"window1"];
if(w != nil)
{
    [w showAll];
}

[builder release];

So there you have it that’s CoreGTK in a nutshell.

There are a variety of ways to help me out with this project if you are so inclined to do so. The first task is probably just to get familiar with it. Download CoreGTK from the GitHub project page and play around with it. If you find a bug (very likely) please create an issue for it.

Another easy way to get familiar with CoreGTK is to help write/fix documentation – a lot of which is written in the source code itself. Sadly most of the current documentation simply states which underlying GTK+ function is called and so it could be cleaned up quite a bit.

At the moment there really isn’t anything more formal than that in place but of course code contributions would also be welcome!

Update: added some pictures of the same program running on all three operating systems.

Hello World on Windows

Hello World on Windows

Hello World on Mac

Hello World on Mac

Hello World on Linux

Hello World on Linux

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).

Screen brightness work around (part 2)

January 19th, 2014 No comments

As mentioned before I am having some issues with my laptop’s hardware and controlling the screen brightness. Previously my work around was to set acpi_backlight=vender in the grub command line options. While this resulted in having full screen brightness it also removed my ability to use my keyboard function keys to adjust the screen brightness on the fly (not so good when you’re on battery). Removing this option allowed me to manually adjusted my screen brightness again but once again always started the laptop at zero brightness. What to do?

While far from a perfect solution my current work around is to use xdotool to simulate key presses on login which raise the screen brightness for me automatically. Here is the script that I run on startup:

#!/bin/bash
for i in {1..20}
do
     xdotool key XF86MonBrightnessUp
done

While this works great it still isn’t perfect. Because xdotool requires an X session it means I cannot run it before one is created. If you were unaware the login screen, in my case MDM, does not run inside of X (it actually starts X when you successfully login). So while this will automatically brighten my screen it won’t do so until I type in my username and password, leaving me to type into a fully dark screen or manually adjust the brightness up enough to see what I’m doing. Hopefully I’ll have a better solution sooner rather than later…




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).

Listener Feedback Podcast Update (December 2013)

December 15th, 2013 No comments

Fix annoying high-pitched sound

November 28th, 2013 No comments

If you’re like me you’ve been suffering through a crazy high-pitched sound emanating from your laptop speakers. Apparently this is a common issue with certain types of audio devices. Thankfully via the power of the Internet I’ve been able to finally find a solution!

It turns out that the issue actually stems from some power saving features (of all things) in the Intel HDA driver. So I simply turned it off and guess what? It worked.

1) Open up (using root) /usr/lib/pm-utils/power.d/intel-audio-powersave

2) Replace or comment out the line:

INTEL_AUDIO_POWERSAVE=${INTEL_AUDIO_POWERSAVE:-true}

3) In its place put the line:

INTEL_AUDIO_POWERSAVE=false

4) Reboot

Hopefully this also works for you but if not check out the site I found the solution at for some additional tips/things to try.




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).

Fix no screen brightness on boot problem

October 14th, 2013 No comments

I recently upgraded my laptop to a brand new Lenovo Y410P and promptly replaced Windows 8 with a Linux install. Unfortunately I immediately ran into a very strange driver(?) issue where, on boot, the computer would default to the absolute lowest screen brightness level. This meant that I would need to manually adjust the screen brightness up just to see the login screen. Thankfully after some help from the excellent people over on the Ubuntu Forums I managed to find a very easy work around.

1) As root open up /etc/default/grub

I did this by simply issuing the following command:

sudo nano /etc/default/grub

2) Find the line that says GRUB_CMDLINE_LINUX= and add “acpi_backlight=vendor” to the list of options.

3) From a terminal run this command to update GRUB

sudo update-grub

4) Reboot!

That’s pretty much it. My computer now boots with the correct screen brightness as one would expect.




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).

Open source project hosting options

September 8th, 2013 2 comments

So you want to host an open source project using one of the many free services available but can’t decide which one to use? If only someone would put together a quick summary of each of the major offerings…

Hosting providers covered in this post:

  • Bitbucket
  • CodePlex
  • GitHub
  • Gitorious
  • Google Code
  • Launchpad
  • SourceForge

Bitbucket

Bitbucket is a hosting site for the distributed version control systems (DVCS) Git and Mercurial. The service offering includes an issue tracker and wiki, as well as integration with a number of popular services such as Basecamp, Flowdock, and Twitter.

Features:

  • Supports both Git and Mercurial
  • Allows private repositories for free, up to 5 users
  • Unlimited repositories
  • Has JIRA integration for issue tracking
  • Has its own REST API

Downsides:

  • Only allows up to 5 users for free (a user defined as someone with read or write access)

CodePlex

CodePlex is Microsoft’s free open source project hosting site. You can create projects to share with the world, collaborate with others on their projects, and download open source software.

Features:

  • Supports both Git & Mercurial
  • Integrated Wiki that allows to add rich documentation and nice looking pages
  • Bug Tracker and Discussion Forums included

Downsides:

  • Often times feels more like a code publishing platform than a collaboration site
  • Primarily geared toward .NET projects

GitHub

Build software better, together. Powerful collaboration, code review, and code management for open source and private projects.

Features:

  • Supports Git
  • Powerful and easy to use graphical tools
  • Easy team management
  • Integrated wiki, issue tracker and code review

Downsides:

  • Only supports Git
  • Quite a few ‘dead’ projects on the site

Gitorious

The Git hosting software that you can install yourself. Gitorious.org provides free hosting for open source projects that use Git.

Features:

  • Supports Git
  • Free project hosting
  • Integrated wiki
  • Can download the software and install it on your own server

Downsides:

  • Only supports Git

Google Code

Project Hosting on Google Code provides a free collaborative development environment for open source projects.

Features:

  • Supports Subversion, Mercurial Git
  • Integrated wiki

Downsides:

  • Not very pretty

Launchpad

Launchpad is a software collaboration platform.

Features:

  • Supports Bazaar
  • Integrated bug tracking and code reviews
  • Ubuntu package building and hosting
  • Mailing lists

Downsides:

  • Only supports Bazaar
  • Geared toward Ubuntu (which can be a downside depending on your project)

SourceForge

Find, Create, and Publish Open Source software for free.

Features:

  • Supports Git, Mercurial, Subversion
  • Integrated issue tracking, wiki, discussion forums
  • Stat tracking

Downsides:

  • Ads
  • A lot of ‘dead’ projects

 

Now obviously I’ve missed some things and glossed over others but my goal here was to provide a quick ‘at a glance’ summary of each. Check the individual websites for more. Thanks to the people over at Stack Exchange for doing a lot of the legwork.




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).

One license to rule them all? Noooooooooope!

August 20th, 2013 No comments

Lately I’ve been taking a look at the various open source software licenses in an attempt to better understand the differences between them. Here is my five minute summary of the most popular licenses:

GNU Public License (GPL)

Requires that any project using a GPL-licensed component must also be made available under the GPL. Basically once you go GPL you can’t go back.

Lesser GNU Public License (LGPL)

Basically the same as the GPL except that if something uses software licensed as LGPL it also doesn’t need to be licensed the same. So if you write a program that uses an LGPL library, say a program with a GTK+ user interface, it doesn’t need to be licensed LGPL. This is useful for commercial applications that rely on open source technology.

v2 vs v3

There are a number of differences between version 2 and version 3 of the GPL and LGPL licenses. Version 3 attempts to clarify a number of issues in version 2 including how patents, DRM, etc. are handled but a number of developers don’t seem to like the differences so version 2 is still quite popular.

MIT

This license allows for almost anything as long as a copy of the license and copyright are included in any distribution of the code. It can be used in commercial software without issue.

BSD3

Similar to the MIT, this license basically only requires that a copy of the license and copyright are included in any distribution of the code. The major difference between this and the MIT is that the BSD3 prohibits the use of the copyright holder’s name in any promotion of derivative work.

Apache

Apache is similar to the BSD license in that you have to provide a copy of the license in any derivative works. In addition there are a number of extra safeguards, such as patent grants, that set it apart from BSD.




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).

The real lesson to take from Elementary OS

August 18th, 2013 No comments

Elementary OS is the latest darling for the Linux community at large and with some good reason. It isn’t that Elementary OS is The. Best. Distro. Ever. In fact being only version 0.2 I doubt its own authors would try to make that claim. It does however bring something poorly needed to the Linux desktop – application focus.

Focus?

Most distributions are put together in such a way as to make sure it works well enough for everyone that will end up using it. This is an admirable goal but one that often ends up falling short of greatness. Elementary OS seems to take a different approach, one that focuses on selecting applications that do the basics extremely well even if they don’t support all of those extra features. Take the aptly named (Maya) Calendar application. You know what it does? That’s right, calendar things.

Yeah, a calendar. What else were you expecting?

Yeah, a calendar. What else were you expecting?

Or the Geary e-mail client, another example of a beautiful application that just does the basics. So what if it doesn’t have all of the plugins that an application like Thunderbird does? It still lets you read and send e-mail in style.

It does e-mail

It does e-mail

Probably the best example of how far this refinement goes is in the music application Noise. Noise looks a lot like your standard iTunes-ish media player but that familiarity betrays the simplicity that Noise brings. As you may have guessed by now, it simply plays music and plays it well.

The best thing about Noise is that it plays music well

The best thing about Noise is that it plays music well

But what about feature X?

OK I understand that this approach to application development isn’t for everyone. In fact it is something that larger players, such as Apple, get called out over all the time over. Personally though I think there is a fine balance between streamlined simplicity and refinement. The Linux desktop has come a long way in the past few years but one thing that is still missing from a large portion of it is that refined user experience that you do get with something like an Apple product, or the applications selected for inclusion in Elementary OS. Too often open source projects happily jump ahead with new feature development long before the existing feature set is refined. To be clear I don’t blame them, programming new exciting features is always more fun than fixing the old broken or cumbersome ones, although this is definitely one area where improvements could be made.

Perhaps other projects can (or will) take the approach that Elementary has and dedicate one release, every so often, to making these refinements reality. I’m thinking something like Ubuntu’s One Hundred Paper Cuts but on a smaller scale. In the meantime I will continue to enjoy the simplicity that Elementary OS is currently bringing my desktop Linux computing life.




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: , , ,

An Ambitious Goal

August 1st, 2013 3 comments

Every since we announced the start of the third Linux Experiment I’ve been trying to think of a way in which I could contribute that would be different from the excellent ideas the others have come up with so far. After batting around some ideas over the past week I think I’ve finally come up with how I want to contribute back to the community. But first a little back story.

A large project now, GNOME was started because there wasn't a good open source alternative at the time

A large project now, GNOME was started because there wasn’t a good open source alternative at the time

During the day I develop commercial software. An unfortunate result of this is that my personal hobby projects often get put on the back burner because in all honesty when I get home I’d rather be doing something else. As a result I’ve developed, pun intended, quite a catalogue of projects which are currently on hold until I can find time/motivation to actually make something of them. These projects run the gamut of little helper scripts, written to make my life more convenient, all the way up to desktop applications, designed to take on bigger tasks. The sad thing is that while a lot of these projects have potential I simply haven’t been able to finish them, and I know that if I just could they would be of use to others as well. So for this Experiment I’ve decided to finally do something with them.

Thanks to OpenOffice, LibreOffice and others there are actual viable open source alternatives to Microsoft Office

Thanks to OpenOffice.org, LibreOffice and others there are actual viable open source alternatives to Microsoft Office

Open source software is made up of many different components. It is simultaneously one part idea, perhaps a different way to accomplish X would be better, one part ideal, belief that sometimes it is best to give code away for free, one part execution, often times a developer just “scratching an itch” or trying a new technology, and one part delivery, someone enthusiastically giving it away and building a community around it. In fact that’s the wonderful thing about all of the projects we all know and love; they all started because someone somewhere thought they had something to share with the world. And that’s what I plan to do. For this Linux Experiment I plan on giving back by setting one of my hobby projects free.

Before this open source web browser we were all stuck with Internet Explorer 6

Before this open source web browser we were all stuck with Internet Explorer 6

Now obviously this is not only ambitious but perhaps quite naive as well especially given the framework of The Linux Experiment – I fully recognize that I have quite a bit of work ahead of me before any of my hobby code is ready to be viewed, let alone be used, by anyone else. I also understand that, given my own personal commitments and available time, it may be quite a while before anything actually comes of this plan. All of this isn’t exactly well suited for something like The Linux Experiment, which thrives on fresh content; there’s no point in me taking part in the Experiment if I won’t be ready to make a new post until months from now. That is why for my Experiment contributions I won’t be only relying on the open sourcing of my code, but rather I will be posting about the thought process and research that I am doing in order to start an open source project.

Topics that I intend to cover are things relevant to people wishing to free their own creations and will include things such as:

  • weighing the pros and cons as well as discussing the differences between the various open source licenses
  • the best place to host code
  • how to structure the project in order to (hopefully) get good community involvement
  • etc.

An interesting side effect of this approach will be somewhat of a new look into the process of open sourcing a project as it is written piece by piece, step by step, rather than in retrospect.

The first billion dollar company built on open source software

The first billion dollar company built on open source software

Coincidentally as I write this post the excellent website tuxmachines.org has put together a group of links discussing the pros of starting open source projects. I’ll be sure to read up on those after I first commit to this 😉

Linux: a hobby project initially created and open sourced by one 21 year old developer

Linux: a hobby project initially created and open sourced by one 21 year old developer

I hope that by the end of this Experiment I’ll have at least provided enough information for others to take their own back burner projects to the point where they too can share their ideas and creations with the world… even if I never actually get to that point myself.

P.S. If anyone out there has experience in starting an open source project from scratch or has any helpful insights or suggestions please post in the comments below, I would really love to hear them.




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 Linux to an external hard drive (+ driver issues)

July 27th, 2013 No comments

While I haven’t quite figured out what I’m going to be doing for this round of The Linux Experiment, I have decided that now is a good time to try something I’ve been meaning to try for a while: get Linux to boot off of an external hard drive. This was actually such a straight forward process, simply install like normal but choose the external drive for the location of all files, that I won’t bother you with the details. The only special thing I did was decide to install GRUB on the external drive making the whole install essentially a completely isolated thing – that way if I turn off the external drive then the computer boots up off of the internal drive like normal, if I boot with the external drive on then GRUB asks me what to do.

The only downside to a setup like this is that I am using USB 2.0 as my connection to the hard drive which means the disk I/O and throughput will be theoretically lower than normal. Arguably I could get around this by using something like USB 3.0 or eSATA but so far in my experience this hasn’t really been an issue. Besides once the OS boots up almost everything is running and/or cached within RAM anyway. In fact that only problems I have run into with running Linux on this desktop were, ironically, driver issues.

First up is the wireless drivers. Yes, it is 2013 and I am still having Linux WiFi driver issues… This issue was unlike any I had seen before – the wireless card was automatically detected, the Broadcom proprietary driver was automatically selected and enabled, it even appeared to work but no matter what I tried it simply would not make a lasting connection to the wireless network. On a whim I decided to just turn off the device driver and, even though the dialog window told me that I would no longer be using the device, things suddenly started working like magic. I have to assume that buried deep within the Linux kernel is already an open source implementation for my wireless driver and that is what is actually working right now. Whatever the actual cause, the device is now working flawlessly.

For future reference: Do not use the device = magically make everything work perfectly

For future reference: Do not use the device = magically make everything work perfectly

The other driver issue I had was again related to a proprietary driver, this time for my graphics card. By default the install used the open source driver and this worked fine. However I have had a long battle with AMD/ATI cards working on Linux without using the proprietary driver and so I decided to enable it in order to avoid any future problems.

graphics

One reboot later and not only was my colour and resolution completed screwed up but I also got this “awesome” overlay on my desktop that said “Hardware not supported”. I tried to take a screenshot of it but apparently it is drawn onto the screen post-display or something (the screenshot did not show the overlay). So for now I am back to using strictly open source drivers for everything and amazingly it is all just working. That’s probably the first time I’ve ever been able to say that about Linux before.




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).

404 Oh No!

July 27th, 2013 No comments

Some of you may have noticed some previously working links going to 404 (page not found) pages. This is due to a change we’ve made in order to make permalinks more consistent among different authors and topics. Sorry for any inconvinence this may cause. On the plus side the website has a search bar that you can use to find what you were looking for 🙂




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: Tyler B Tags:

Announcing The Linux Experiment (The Third!)

July 23rd, 2013 No comments

That’s right, time for round three!

If you’ve been following this website in the past you know what this means. This time around our rules are simple: give back to the community. With this idea in mind the participants, known as guinea pigs, will attempt to use their unique passions, interests and talents to give something back to the world of Linux and open source software. The goal is purposely designed to be generic and open ended – we want each guinea pig to interpret the rule in their own way and let their creativity determine how they will give back.

Some ideas we’ve tossed around to accomplish this goal have been:

  • Writing about a unique way to setup open source software to accomplish something
  • Trying out and writing about a new distribution that offers a different experience
  • Giving back to a distribution you use or like
  • Helping a project by submitting code patches, documentation updates, artwork, UX design or simply spreading the word
  • Starting your own project to accomplish something
  • Etc.

So join us dear reader as we chronicle giving back to the community. Oh and don’t be afraid to take part in your own way either 😉




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: Tyler B Tags:

Make printing easy with the Samsung Unified Linux Driver Repository

July 13th, 2013 No comments

I recently picked up a cheap Samsung laser printer and decided to give the Samsung Unified Linux Driver Repository a shot while installing it. Basically the SULDR is a repository you add to your /etc/apt/sources.list file which allows you to install one of their driver management applications. Once that is installed anytime you go to hookup a new printer the management application automatically searches the repository, full of the official Samsung printer drivers, finds the correct one for you and installs it. Needless to say I didn’t have any problems getting this printer to work on linux!




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: Hardware, Linux, Tyler B Tags: , ,

Listener Feedback Podcast Update (July 2013)

July 12th, 2013 No comments

A couple new Listener Feedback podcast episodes have been released in case you missed them:

So grab the MP3 or Ogg version of this Creative Commons podcast and enjoy!




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 6

July 9th, 2013 3 comments

It’s that time again 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:

  • Fedora 18 (GNOME)
  • Fedora 18 (KDE)
  • Fedora 19 (GNOME
  • Fedora 19 (KDE)
  • Kubuntu 13.04 (KDE)
  • Linux Mint 15 (Cinnamon)
  • Linux Mint 15 (MATE)
  • Mageia 3 (GNOME)
  • Mageia 3 (KDE)
  • OpenSUSE 12.3 (GNOME)
  • OpenSUSE 12.3 (KDE)
  • Ubuntu 13.04 (Unity)
  • Xubuntu 13.04 (Xfce)

I even happened to have a Windows 7 (64-bit) VM lying around and, while I think you would be a fool to run a 64-bit OS on the limited test hardware, I’ve included as sort of a benchmark.

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

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

The tests were all done using VirtualBox 4.2.16, 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 between July 1st, 2013 and July 5th, 2013 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. This time around however I’ve changed how things are measured slightly in order to be more accurate. Measurements (on linux) were taken using the free -m command for memory and the df -h command for disk usage. On Windows I used Task Manager and Windows Explorer.

In addition this will be the first time where I provide 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). Secondly there may be some distributions that don’t appear on all of the graphs, for example because I was using an existing Windows 7 VM I didn’t have a ‘first boot’ result. As always feel free to run your own tests. Thirdly you may be asking yourself ‘why does Fedora 18 and 19 make the list?’ Well basically because I had already run the tests for 18 and then 19 happened to be released. Finally Fedora 19 (GNOME), while included, does not have any data because I simply could not get it to install.

First boot memory (RAM) usage

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

 

All Data Points

All Data Points

RAM

RAM

Buffers/Cache Only

Buffers/Cache

RAM - Buffers/Cache

RAM – Buffers/Cache

Swap Usage

Swap Usage

RAM - Buffers/Cache + Swap

RAM – Buffers/Cache + Swap

Memory (RAM) usage after updates

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

After_Updates_All

All Data Points

RAM

RAM

Buffers/Cache

Buffers/Cache

RAM - Buffers/Cache

RAM – Buffers/Cache

Swap

Swap

RAM - Buffers/Cache + Swap

RAM – Buffers/Cache + Swap

Memory (RAM) usage change after updates

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

All Data Points

All Data Points

RAM

RAM

Buffers/Cache

Buffers/Cache

RAM - Buffers/Cache

RAM – Buffers/Cache

Swap Usage

Swap

RAM - Buffers/Cache + Swap

RAM – Buffers/Cache + Swap

Install size after updates

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

Install Size

Install Size

Conclusion

Once again I will leave the conclusions to you. This time however, as promised above, I will provide my source data for you to plunder enjoy.

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).

How to backup and restore a Trac project

July 4th, 2013 No comments

If you use Trac as your bug and progress tracking tool then you too may one day need to take a backup of it or move it to a new server like I had to the other day. Thankfully, as I discovered, it is a relatively straight forward process. Here are the steps to backup and restore a Trac project.

Take a hot backup of your existing install. This is essentially a backup from a fixed point that you can take while still using your Trac at the same time (great for having no downtime).

trac-admin [/path/to/projenv] hotcopy [/path/to/backupdir]

For example:

trac-admin /var/www/trac/projectx hotcopy /home/awesomeadmin/trac_backup/projectx

In order to restore it on another server you just need to create the project from scratch (i.e. using initenv) like this

trac-admin [targetdir] initenv

and then simply replace the install directory contents with the backed up contents. Strictly speaking I’m not even sure if you need to initenv but that’s how I did it and it worked.

Hopefully this works for you as well. Happy… err… Trac-ing?




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: Tyler B Tags: , ,