Friday, May 31, 2013

Dated Hardware, Waiting for Hardware and the Nokia N900 in 2013

The Nokia N900 was released in November of 2009 - three and a half years ago. When I bought my first N900 in January of 2010 it was a huge upgrade for me in terms of both speed and software freedom (coming from a Blackberry). The idea of having a computer - a true computer - that was also a phone was amazing. The same device I used to send text messages, I also installed applications on using apt-get. True multitasking - my applications stayed open until I closed them, not until the operating system decided it wanted to kill them. I didn't mind paying the 450 USD it cost to purchase the brand new N900 out of contract - this was an awesome piece of technology!

Fast forward to 2013. Three years later I have gone through 2.5 Nokia N900s (I say 2.5, because the first two each broke in different ways and I was able to build a working device from their left overs) and still have it sitting on my desk as I write this. Three years is a long time in the world of mobile hardware and the N900 easily shows plenty of signs of aging. Compared to my wife's Nexus 4, it loads applications and web sites slowly.

So why is it I hold onto hardware/software that deserves an upgrade? Simple - no one has released a comparable replacement. At first I did not want to trade my true Linux operating system in for this dribble called Android everyone raves about. Upon giving Android a chance though - I could make do with it. The HTML5 supporting browsers on Andriod really provide a decent web experience (which beyond text messaging is what I mainly do on a mobile device).

The hold up then? The hardware. I'm not talking about the speed of the hardware though - I'm talking about the lack of design. Almost every modern mobile that is sold today is a pure touch device. Hardware keyboards are a thing of the past it seems.

Am I truly the last person left alive who doesn't like a software keyboard taking up half of my sub-10 inch screen while I type something?

When I search for modern cell phone hardware I certainly feel that way.

I have hope though! Within the next year we are expecting at least three new mobile operating systems to enter the landscape:
  • Ubuntu Mobile
  • Tizen
  • Firefox Mobile
I hope against all open that one of the hardware makers supporting these operating system breaks the current tread of touch-only devices. Maybe then I and stop picking up old N900s on Ebay when my existing one breaks!

~Jeff Hoogland

Monday, May 13, 2013

Samsung ARM Chromebook Review

The Samsung ARM Chromebook is one of a few ARM devices that I prepare Bodhi Linux images for. As such I've owned the hardware for almost six months now and during this time I've used it a fair amount. The goal of this post is to provide a comprehensive review of the product to see if it is something that could be useful to you.

Cost - 
Lets start with one of the first draws - the price point. The Chromebook comes in at under 300 USD. 250 USD plus shipping and handling to be exact.

Performance -
In terms of speed the Chromebook processor is snappy compared to other netbook offerings and ARM chipsets in general. The Chromebook sports the Samsung Exynos 5 1.7ghz dual core processor and 2gigs of DDR3 RAM. This coupled with the 16GB solid state hard drive allow the Chromebook to boot fully from a cold start in just a few seconds.

Under Chrome OS the Chromebook happily plays a variety of multimedia formats. Including 720p video files, 1080 flash streams, and Netflix.

Connections - 
In terms of "ports" the Chromebook sports two USB (one 3.0 and one 2.0), an SDHC card slot, HDMI video output, and a combination audio input/output jack. While all these ports are plenty functional I do have a few comments about them.

First - both USB ports, the HDMI and the power plug are all right next to each other on the back of the netbook. This means if you have all these ports in use at the same time space gets kind of tight (it also means if you have a clunky USB device it is going to block other ports).

Second - because the Chromebook has such little storage by default, it can be nice to use a SD card as extra space. Sadly, unlike most netbooks - when you insert a SD card into the Chromebook it does not go completely inside of the netbook. Meaning if you leave an SD card in the slot while transporting the netbook it is likely to get damaged.

Finally - maybe this one is just me, but I dislike not having traditional two ports for audio input/output. My traditional headsets do not work when using a Google hangout with this netbook.

Size & Feel - 
The Chromebook has an awesome form factor. Weighing in at just under 2.5 pound (about 1.1 KG) and having dimensions of 289.6 x 208.5 x 16.8 - 17.5 mm it is a sleek little device.

Personally I like Chicklet keyboards on laptops and the Chromebook keyboard is no exception for me. The keyboard layout on the Chromebook is one that is best described with an image though:


As you can see there is no super (or "Windows") modifier key, Capslock has been left off in favor of a "search" button, and while the top row of buttons may not read F1-F10 - under non-ChromeOS operating systems they return these values.

One design choice I found slightly odd with the Chromebook is that even though the hardware supports a "right" click function, all context menus within Chrome OS are called up with a two finger touch ("right" clicking in Chrome OS is no different than any other single finger touch).

Battery & Screen - 
The battery life on the Chromebook is one of the largest draws I think. It is easily one of the lightest pieces of hardware with a lengthy battery life. Through average web use the Chromebook sees just shy of seven hours of usage before you need to find an outlet.

While the screen resolution could be better, the Chromebook's 1366x768 screen resolution at least enables you to watch 720p video in their native quality.

Misc Thoughts -
I have had some trouble using the HDMI output on the Chromebook - the graphics drivers on Chrome OS seem to be fairly buggy. I've experience full system lock ups when attaching an external screen while the OS is running - but this does not happen every time and I cannot reproduce it consistently.

One that keeps me from using the Chromebook as my primary mobile computer over my old trusty Asus T101MT is that Dropbox does not create their software for ChromeOS or generic ARM Linux devices to date. I store a lot of data on this service and accessing it all via a web portal instead of having it sync to the system's local drive is very annoying. If you are open to using Google drive this is a non-issue, but I haven't had the time to make this jump as of yet.

Closing -
Who would I recommend the Chromebook to? Anyone who needs a device for accessing the web, but requires a keyboard to get their work done. If a large deal of your computing time is spent on Gmail, Facebook, Netflix, online shopping or Youtube then the Chromebook is the perfect device for you.

Who would I not recommend a Chromebook to? Someone that is looking to use it as their sole computer. While a lot of people use the web a lot - most people still have at least one or two desktop applications they need access to (such as my tie to drop box). Because of this Chrome OS's "web based" application eco-system currently still leaves some to be desired.

Do you own a Samsung ARM Chromebook? If so what are you thoughts on the device?

Cheers,
~Jeff Hoogland

Sunday, March 31, 2013

Bodhi Linux 2.3.0 Released

After almost exactly three months since our Bodhi 2.2.0 release the Bodhi team and I are happy to announce the next update release for our 2.x.y series - Bodhi Linux 2.3.0. Again because this is a minor update release people who are already using our 2.x.y branch can simply upgrade to this release via their package manager. Something else I would like to mention is that next month our 1.x.y series release will be reaching its end of life next month (meaning our repos for it will be fully shutdown) so this is a great time to upgrade to our matured 2.x.y release if you've been waiting.

For those who don't care to hear my ramblings, you can find direct download links for our ISO images on Source Forge here and then torrent downloads for the ISO images here (please help seed for a few days if you can).

As with our 2.2.0 release there are three disc downloads for this version:

  • 32bit featuring a current PAE enabled kernel
  • 32bit featuring a non-PAE kernel with older hardware support
  • 64bit featuring a current kernel
Software wise we see the following updates with this release:
And of course there are a number of other application updates in the Bodhi repos (not included by default) such as Firefox 19.0.2, Chromium 25, nVidia 310 drivers and LibreOffice 4.0.1

Of course we have some fresh looks for this Bodhi release in terms of art as well! You will find the following default themes on this Bodhi disc:

Angelic


Miguel


Egypt


Vision


Bodhi Forum


Finally - please do not comment on this post asking for help with an issue you have with Bodhi. Instead open a support request on our user forums.

Cheers,
~Jeff Hoogland

Wednesday, March 20, 2013

Mir, Wayland and the Future of Bodhi Linux


Things have been a little quiet around my blog of the late. At the beginning of last month I started a full time position doing some IT related tasks for a major insurance company where I live in central IL. Between the new job, playing Magic, spending time keeping Bodhi things up to date, and preparing to get married in less than a month - I haven’t had time to post as much as I’d like to on here.

Today I would like to take a moment to discuss a topic that has received much attention on Linux blogs/news sites in recent weeks – Ubuntu’s concept for the Mir display server. I would like to start by pointing out I’ve said the concept of Mir. That is right folks – at this point it is just a concept, nothing more. Not long ago Ubuntu announced they’d be moving to Wayland. We all know exactly how much came from this announcement. Because of this history I’m going to reserve my judgment of Mir until we see it actually created and put into use.

Lots of people have been jumping to even more conclusions as to what exactly Mir means for derivatives of Ubuntu – such as the Bodhi project I manage. Currently Mir means absolutely nothing for Bodhi. We intend to continue following our close relationship with the upstream Enlightenment developers (we are after all an E-centric distro) and at this current point in time the Enlightenment team has zero plans to support Mir (which is fine, because again it is still nothing more than a concept). The E team however has been actively working on porting the EFLs/E desktop to be functional on top of Wayland.

Does this mean Bodhi will move to using Wayland for our display server? No it does not. Does Ubuntu moving to Mir (some year[s] from now) mean Bodhi will be rebased on another Linux distribution (such as Debian)? No it does not. Bodhi uses Enlightenment for it’s desktop because I believe it is the best desktop Linux has to offer. As long as X11 remains the best display server Linux has to offer Bodhi will continue using it. As long as Ubuntu remains the best/most supported core to build a distribution off of Bodhi will remain being derived from it.

That being said, our next major Bodhi release (3.0.0) will not be released until summer of 2014. A lot can happen in terms of software (and technology in general) over the course of 15 months – so nothing is set in stone. When it comes time for our next major release we will be re-evaluating all aspects of our project to ensure we are choosing technologies that are the best for our end users. After all, what good is an operating system if it doesn’t serve it’s end users well.

Speaking of Bodhi releases – keep an eye on our testing forum for Bodhi 2.3.0 pre-release discs within the next twenty-four hours. That update release is scheduled to be out by the end of this month.

Cheers,
~Jeff Hoogland

Tuesday, February 26, 2013

A Fat Stack of Bodhi Linux

When I first started preparing Bodhi ISO images almost two and a half years ago I set out with the goal of providing a clutter free operating system powered by the latest Enlightenment desktop. We call what we do "minimalist" meaning it doesn't come with a whole lot by default. This ideology isn't for everyone, though. Thankfully, the power of choice is something that greatly empowers free software development.

Today, I would like to offer a bit more choice for Bodhi users. I would like to share with you all my "friends and family" version of Bodhi Linux. You can grab the ISO image for this fat stack of Bodhi on source forge here. I call it my "friends and family" disc because when I am pressed for time I can't always sit down and install all the extra software "normal" people need to use their PC. This image allows me to skip the installing software step after I install the operating system.

This ISO image is something I've been working on and using as an install media for my non-personal systems for awhile now and I think it is finally in a state that I am happy sharing it. It is simply a Bodhi 2.x branch live/install CD powered by a Linux 3.5 kernel and the latest E17.1 Enlightenment desktop. It comes with a bunch of software pre-installed that should keep most people happy:


This is a 32bit disc image and no I will not be preparing a similar 64bit disc. I intend this disc for home systems, for which I recommend 32bit operating systems. Users installing from this disc can get support on the Bodhi Forums just as if they had installed from the normal disc.

~Jeff Hoogland

Saturday, February 16, 2013

Comparison of Linux Desktops OpenGL Performance

With Steam officially being released for Linux I took some time out this evening to run a few benchmarks on my Ubuntu 12.04 based Bodhi system to see how a few of the different modern Linux desktops compare in terms of OpenGL performance with the source engine. Please do not take my numbers to be anything super scientific or precise. I simply recorded a short demo using Team Fortress 2, loaded TF2 from Steam under each of the Linux desktops with no other background applications running and ran the demo through a built in source engine bench marking tool.

The benchmarks were run on my very modest gaming laptop which sports an i7 processor, 6GB of RAM, and an nVidia 330m GT graphics card. I utilized the Steam recommended nVidia 310 driver for these tests. All the desktop setups I used were "stock" from the Ubuntu 12.04 repos, minus E17 which is using the E17.1 snapshot and Bodhi's laptop profile with compositing enabled.

Lets get right to the data shall we? You all love charts I hope!


It is clear from the bar graph that E17 came out towards the top and Gnome Shell was near the bottom. Here are the numbers to a single decimal place:
  • Gnome Shell - 51.5 FPS
  • KDE   - 55.0 FPS
  • XFCE - 55.7 FPS
  • Unity  - 60.5 FPS
  • KDE, Disable Compositing on Full Screen - 63.2 FPS
  • LXDE - 66.5 FPS
  • E17     - 66.7 FPS
I was not surprised when I saw E17 and LXDE had the best performance, they are after all some of the best light desktops today. What did shock me though was that XFCE - which claims to be fairly light - was very low in terms of performance! 

Based on the above numbers XFCE performed around 17% slower than both LXDE and E17, while Unity was around 9% slower than the lighter desktops, and Gnome Shell was a staggering 23% behind.  One other thing worth noting is that KDE has a HUGE performance difference when you check the "disable compositing on full screen applications" box in your Kwin settings. In fact ignoring this setting loses you around 13% in performance:


Obviously someone should run some further tests (I know I plan to when I get some more time), but from my initial small test it is obvious - if you are looking to game on Linux your choice of desktop very clearly matters!

~Jeff Hoogland

Friday, February 1, 2013

Tutorial 2: ELM Images, File Selector and Popups

This is the second post in my series on developing GUI applications in Elementary using Python. Today we are going to continue building on the Hello Elementary example I started in the first tutorial. In today's post I will only be covering the code that is different from our previous examples, so if you haven't looked that one over yet please take a moment to do so now.

You can find the full source code for all of today's examples here.

Example 3:
We are going to start off by displaying a static, pre-defined image in our GUI:


It only takes us 8 lines of actual code to create and display the above image in our program:

    #Creates an Image object that displays an image
    ic = elementary.Image(window)

    #Use the os module to get the current path to our .py file. Our image is relative to our .py We do this because it is best to use the absolute file path to images for the best results.
    location = os.path.dirname(os.path.abspath(__file__))

    #Tell our icon to auto-fill open space
    ic.size_hint_weight_set(evas.EVAS_HINT_EXPAND, evas.EVAS_HINT_EXPAND)
    ic.size_hint_align_set(evas.EVAS_HINT_FILL, evas.EVAS_HINT_FILL)

    #Here we set the image we want our icon to display
    ic.file_set("%s/images/logo.png"%location)

    #Optional, lets add mouse over text to our image
    ic.tooltip_text_set("Look a pretty picture!")

    #Lets show our icon
    ic.show()

    box.pack_end(windytax)
    #Pack our icon between our text and button
    box.pack_end(ic)
    box.pack_end(button)

In this example we utilize the elementary Image object to display our selected .png file.

Example 4:
Very rarely do we want to simply display a single image for as long as our program is running. So lets give the user the ability to change the image we display in our program:


Elementary has a built in FileselectorButton object that when clicked presents our user with a nice file selector GUI:


The new code to add this file selector button looks like:

    #Creates a "FileselectorButton" object. This is a button (just like we have created before) except that when it is click it automatically opens a file selector window
    fsb = elementary.FileselectorButton(window)

    #We can set the text of our fsb just like a normal button text
    fsb.text = "Change Image"

    #Tooltip for mouse over
    fsb.tooltip_text_set("Click Me!")

    #This tells our file selector window what to do when our user selects a file. The first argument is the callback function we want run and our second argument is our image object we want to change the display of
    fsb.callback_file_chosen_add(change_image, ic)

    #Show our button
    fsb.show()

    box.pack_end(windytax)
    box.pack_end(ic)
    #Pack our file selector button between our image and button
    box.pack_end(fsb)
    box.pack_end(button)

    window.resize_object_add(box)

    window.resize(300,300)

    window.show()

#Our fileselector callback. The file argument is the fileselectbutton object. The second argument is the full path to the file that was selected. The final argument is the image object we passed to this callback
def change_image(fsb, file_selected, image):
    #Check to make sure a file of some sort was selected. If nothing was selected file_selected will equal None type
    if file_selected:
        #These are the extensions we will allow our program to display
        validExtensions = [".png", ".jpg", ".gif"]

        #Use the os module to easily get the extension of our file
        fileName, fileExtension = os.path.splitext(file_selected)

        #If the extension is in our validExtenions lets check the image we are displaying!
        if fileExtension in validExtensions:
            image.file_set(file_selected)

Example 5:
Lets add one finishing touch to our application. If our user selects a file to display that doesn't have a valid image extension lets send them a popup telling them why the image displayed wasn't changed:


Showing a popup of this nature is fairly easy using elementary's Popup object. So the final edit to our code looks like this:

#This time we also pass the window object to our change image function. The reason for this is that our popup object needs a parent window object
def change_image(fsb, file_selected, image, window):
    if file_selected:
        validExtensions = [".png", ".jpg", ".gif"]

        fileName, fileExtension = os.path.splitext(file_selected)

        if fileExtension in validExtensions:
            image.file_set(file_selected)
        else:
            #if we have an invalid extension lets give the user a popup message telling them why the image didn't change

            #Create a popup message
            popup = elementary.Popup(window)

            #Set the title of our popup
            popup.part_text_set("title,text", "Invalid File Extension")

            #Set the text of our popup
            popup.text = "File %s has an invalid file extension of %s"%(fileName, fileExtension)

            #Create a button object
            bt = elementary.Button(window)

            #Set it's text
            bt.text = "OK"

            #Define a callback that is called when the button is clicked, lets pass our popup object to this call back so we can close the popup when the user presses OK
            bt.callback_clicked_add(bnt_close, popup)

            #Sets content for our popup. The first argument is an arbitrary name for the content piece and the second argument is the elementary object you would like displayed for the content
            popup.part_content_set("button1", bt)

            #Show the popup to our user
            popup.show()

#The callback for our popup's OK button. The first agurment is the button object itself and the second object is the popup we passed to it
def bnt_close(bt, popup):
    #Lets delete the popup so it goes away
    popup.delete()

Hope everyone learned something today! Have any questions feel free to drop a comment below or start a discussion on our user boards.

Resources for this Lesson:
~Jeff Hoogland