CodeMiller

Installing Linux on a Samsung Series 9

When I bought a Samsung Series 9 (900X3A-A03AU) notebook recently I was intending to install Linux on it, but I wasn’t sure which distribution to go for.

I started out with Linux Mint 12 (Gnome + MATE) and while the installation was easy and I didn’t have any of the kernel panic issues I’d seen mentioned on various forums, not everything went smoothly.

WiFi did not seem to work on the MATE desktop, even after I’d installed the recommended Broadcom driver, but I eventually managed to get it functioning on Gnome Classic.

I built an optimised kernel based on one blog and tweaked the touchpad settings and key mappings in keeping with some other posts, but I still couldn’t get the core touchpad gestures working properly and only half my function keys were responding correctly.

After much fiddling, I managed to get the function key meant to turn on/up the backlit keyboard to respond, but the key to turn it off/down was still inactive.

This wasn’t a very useful state of affairs as my focus was to avoid draining my battery with a constant backlight, so I decided to give another Linux distribution a try. Fedora was the distro the Samsung Series 9 key mapping fix posts I’d found were written about, so I gave it a go.

It took less time to get everything up and running with Fedora and the key mapping hacks I’d tried previously now worked a treat, finally giving me control of all my function keys.

As described below, several things that I had to battle with on Linux Mint just worked out of the box with Fedora.

In the few days since, I have noticed it is slower to load and shut down Fedora than it was with Mint and there do seem to be a couple of little bugs to iron out, but overall I’ve been happy with the OS so far.

Here are the steps I went through to install Fedora 16 on my Samsung Series 9, along with some of my observations:

• Backed up my system and data using Windows 7’s Backup and Restore tool and the Samsung Recovery Solution tool.
• Downloaded the Fedora 16 Desktop 64-bit ISO.
• Used Universal USB Installer and a spare USB stick to create a Fedora USB installer.
• Pressed F2 to get to the BIOS settings and selected Boot > Boot Device Priority. Moved ‘USB HDD’ to the top, then selected ‘Save Configuration and Exit’. For the record, it seems F1 is the shortcut for the Windows Boot Manager and F11 gets you to Edit Boot Options on a Samsung Series 9.
• Put the USB stick in the USB port on the right-hand side of the notebook, which can handle bootable media, and booted into Fedora.
• Clicked Activities > Install to Hard Drive to kick off the installation and then followed the prompts. I had already reduced the size of my Windows partition and created plenty of free space for Linux with GParted during my Mint installation. During the Fedora installation, I still chose the custom install option to ensure my partitions were the way I wanted (there’s some advice on partitioning for Fedora here).
• When I logged in to Fedora, I found the screen brightness, touchpad and volume function keys already worked. The other function keys did not seem to work. WiFi was working out of the box. Regarding the touchpad, the right-hand side was set as a scrollbar and I had to actually press down the touchpad to click, rather than just tapping. No other touchpad gestures seemed to work.
• As I am not a fan of Gnome 3, I switched to a Gnome Classic look by installing dconf-editor and using gnome-fallback mode as per the instructions here. 
• Ran ‘sudo yum update’ in a terminal. Found (by typing uname -r) that the kernel had been upgraded to a 3.3 version. 
• Went to Applications > System Tools > System Settings > Mouse and Touchpad and selected ‘Enable mouse clicks with touchpad’, ‘Disable touchpad while typing’ and ‘Two-finger scrolling’. These gestures all then worked.
• Opened the ‘/etc/default/grub’ file, added ‘elevator=deadline noatime discard i915.i915_enable_rc6=1 i915.lvds_downclock=1’ to grub_cmdline and changed grub_default to 0. Then ran ‘grub2-mkconfig > /boot/grub2/grub.cfg’, as per instructions here (although some of that blog post’s suggested options I didn’t think were necessary so I have left them out).
• Went back into touchpad settings and unticked ‘Disable touchpad after typing’, instead using a custom script to set the time to wait before enabling the touchpad after typing, as described here. Found 0.2 seconds was about right for me.
• Found Bluetooth was always on at start up, so disabled the Bluetooth Manager through Startup Programs (type gnome-session-properties in a terminal) and ran the command ‘chkconfig bluetooth off’ to stop it starting automatically at boot time, based on advice here.
• Set up Git and cloned the ‘samsung-laptop’ Git repo, continuing to follow instructions from this blog.
• Installed ‘kernel-devel’ and other packages for building a kernel listed here. Ran ‘make’ to compile the samsung-laptop module and then ran ‘insmod drivers/platform/x86/samsung-laptop.ko’ to load it. Copied the .ko file to ‘/lib/modules/$(uname -r)/kernel/drivers/platform/x86/’ and ran ‘depmod -a’ (all with sudo).
• Created extra keymaps and scripts as per the instructions here and found all function keys now worked. Note that this blog’s custom shortcut commands are missing the ‘bin’ directory from some filepaths; make sure you use ‘sudo /home/username/bin/samctl.sh’ if that is where your script is.
• Added notifications to each action in the samctl.sh script, for example:

  wlan_state_value="$(cat $wlan_state)"
  if [[ $wlan_state_value -eq 0 ]];
    then echo "1" > $wlan_state
    su username -c "notify-send --hint=int:transient:1 -t 250 'WiFi:' ON"

  The hint option means each notification does not have to be manually dismissed, which would be a pain.
• Found there is a bug in the notification-daemon that does not accept boolean values like this to be sent as ints, even though boolean isn’t a permitted hint type in notify-send. This causes the daemon to crash when you run notify-send with this hint option.
• Could have just taken out the ‘—hint=int:transient:1’ but was not content with manually dismissing function key alerts. Found someone had written a Debian patch for the bug but couldn’t find a patched RPM file, so downloaded the latest source, applied the patch to the C code, rebuilt the RPM (using this as a guide) and installed the new RPM (plus emailed the authors so the patch will hopefully end up in the next version). This fixed the alert problem but I found the expire-time flag (-t 250) did not seem to have any impact, which I decided was a problem for another day.
• Found the battery duration prediction was 4h10m at full charge. Installed powertop and tuned.
• Discovered the keyboard shortcut to open a new terminal was not working. Installed libgnome based on this advice and found it worked after a restart.
• Had a look at the kernel config (in ‘/boot/config-[kernelVersion]’ file) and decided against building a custom kernel like I did for Mint. For those who might like to do so, found a wiki on this here.

That’s all I’ve had the chance to do so far. Hopefully someone finds it helpful. Happy hacking!

Next transaction: 10 influences developing a dev

I’ve heard it said (and tweeted) that if you don’t hate code you wrote six months ago, then you haven’t learnt enough in the past six months.

It didn’t even take one month for me to start despising the ‘fiscal challenge’ code I blogged last year — I admitted it didn’t seem right to me in the original post — but at the time I wasn’t sure how best to refactor it.

Recently I had reason to reattempt the same cash dispenser programming exercise, and I soon realised the best approach was not to refactor my old code at all but rather to start from scratch, taking into account all I had been learning.

The finished product was vastly different from my first effort. While I would still not argue that it is perfect code by any means, I believe the second version has a much cleaner and more maintainable structure with better separation of concerns. Here is a snippet of the new code, representing the same portion of the exercise as what I first posted.

As I mentioned the Haskell programming language in the original post I thought I should try my hand at a more functional solution as well. I came up with a different algorithm for the Haskell version (and was aiming for readability rather than brevity) but this code snippet addresses the same part of the cash dispenser problem.

Looking over the new code I was quite surprised at the degree of difference a few months of experience can make. As this is my first blog for the new year I thought it would be appropriate to spend some time reflecting on what influences or practices have been helping me to improve my programming. I came up with the following:

1. The right learning environment. If you are exposed to best practices daily, you are likely to start to incorporate them into your coding. 
2. Talented technical mentors. It’s much easier to learn from experienced engineers than to try to figure out everything on your own.
3. Using test-driven development. You have to be disciplined to work this way but it can produce leaner, more testable code and encourages a focus on requirements.
4. Pair programming. When you’re new in a team and/or to professional coding it really helps to see how others do things and the standards they apply. I have also picked up some nifty keyboard shortcuts this way. 
5. Exploring functional programming. It makes you think about problems differently and helps you to write better code no matter what language you are using, as I have argued in a previous rant.
6. Learning new languages. Different programming languages have been designed to solve different problems. If you only know one you’re bound to be missing something from your toolkit.
7. Reading informative books. If you’re coding in Java, I can’t recommend Effective Java enough. The Pragmatic Programmer is another worthy entry on the must-read list.
8. Studying code libraries. There’s a lot of fantastic stuff both in standard language libraries and beyond them, but you’re never going to use it if you don’t know it’s there.
9. Practice. It’s all very well to code for work or study, but there are many more opportunities than that. Playing with Android has been fun and instructive for me. Coding competitions and open source projects are other avenues I’d like to further explore.
10. Attending coding meet-ups and conferences. It’s a great way to get exposed to new technologies, new networks of people and new ways of doing things. Special mention goes to Code Retreat; you are forced to delete your code after each iteration so you can truly start afresh in the next one, which is a valuable lesson.

That’s what came to mind for me, but I would be interested to hear what more experienced software engineers would add to the list. Please let me know if there is anything I’ve left out that has helped you to improve your coding over the years.

Haskell will improve your coding, Simon says

THERE were many brilliant talks at the YOW! Australia Developer Conference in Brisbane this week but for me I think the highlight was Simon Peyton Jones’ keynote.

The moment the Haskell inventor took to the stage barefoot and full of beans I knew we were in for a treat, but it wasn’t just his entertaining speaking style that made the presentation memorable (for the record, I also found Damian Conway, John Hughes and Jim Webber to be consummate showmen).

What set apart Simon’s talk for me was the timeliness and relevance of his message.

As the Microsoft researcher (pictured) said, he probably wouldn’t have been invited to give a keynote on functional programming five years ago but something has been happening in the software industry that has been increasing the popularity of the paradigm.

It seems Haskell really has escaped from the Ivory Tower and is influencing today’s programming styles and languages, and for good reason.

As Simon enthused: “Learning Haskell will make you a better Java programmer … it will rewire your brain in a way that will make you write better Java programs. What I’m trying to do here is not so much to infect your hard drives but to infect your brains … these ideas really are important.”

He stressed that learning key ideas such as purity and types is more important than learning any particular language.

I totally agree and feel this message needs to be declared as I have found that not everyone appreciates the value of the functional programming approach.

It was only this year that I graduated from my IT studies, but I was unable to take a subject on functional and logic programming at my university as the course had been removed from the curriculum.

Thankfully, one passionate professor taught curious students about FP in the library in his own time. I am grateful for that opportunity and believe without that experience, I probably wouldn’t have chosen to delve further into Haskell this year.

Perhaps my university’s decision is not indicative of what is happening broadly (at least I certainly hope not!), but I have come across plenty of programmers who did learn functional programming at uni but consider it too difficult or esoteric to be worth putting into practice today. I hope they hear a talk like Simon’s and reconsider their position.

I am still learning, but I have already experienced many benefits from exploring functional programming with Haskell. It helps me to look at programming problems differently and also offers many widely applicable techniques to improve my code.

When one of my fellow Java developers at work told me about an Optional type the team had implemented, I could immediately equate it with Maybe in Haskell and understand what he was going on about. I’ve found concepts such as immutability, list filtering and lazy evaluation to be extremely relevant, even if they don’t always make for pretty code when expressed in Java.

If any coders out there still haven’t jumped on the bandwagon and started to take functional programming seriously post-university, I encourage you to Learn You A Haskell (or some other FP-oriented language) For Great Good.

You don’t have to do it alone. I joined my local functional programming group and have also found a small study group with which to go through the Learn You A Haskell book.

Hopefully when these ideas are well understood across the programming profession, together we can create the nirvana Simon described of a completely safe, useful programming language.