saurabhsood91Upgrading from openSUSE 13.1 to openSUSE 13.2
openSUSE 13.2 is out and gets a host of new stuff. Right from new desktop environments (KDE, GNOME, MATE…its got it all), there is plenty of stuff to write about. For those running on openSUSE 13.1, upgrading is pretty simple and takes only about 20 minutes.
1.) Open Software Repositories from YaST
2.) Disable all the unnecessary repositories (keep only OSS, debug, update repositories)
3.) Change the 13.1 in the Repository URL to 13.2
4.) Open Terminal. As root, run ‘zypper refresh’
5.) Once the repositories are refreshed, run ‘zypper dup’
6.) Go through accepting some licenses. Let the magic run
This should upgrade the system from 13.1 to 13.2. Have fun 
MemberopenSUSE 13.2 release and other goodness
Today happens to be my birthday, I’ve taken some days off work and there’s a lot of good stuff going on.
Tumbleweed is dead, long live Tumbleweed
Earlier today Richard Brown informed that the planned merge of Tumbleweed into Factory has been completed. So starting from today the “old” Tumbleweed is dead, and Factory will continue as a rolling release distro under the name openSUSE Tumbleweed.
Black Other Half
As a birthday present I got the Keira Black Other Half from the Jolla Store for my Jolla. Which of course isn’t just a cover, it’s a smart cover which also adds a cool ambience including ringtones etc.
Kickstarter for TOHKBD
The Kickstarter crowd funding campaign for TOHKBD (The Other Half Keyboard, scroll down on the link for videos and more). A physical QWERTY keyboard for the Jolla smartphone, has kicked off today, and so far gotten off to a flying start.
openSUSE 13.2
Of course most importantly openSUSE 13.2 was released minutes ago.
This is the first release based on the stabilized rolling release distro Factory (well, Tumbleweed, starting today). It features a greatly improved installer, Plasma 5 as a tech preview, QML based NetworkManager plasmoid, Btrfs+XFS as default filesystem. See here for a detailed list of new features.
Also the nice and stable, feature frozen KDE 4 workspace should be mentioned. A lot people who used KDE 3.5.x back in the day, will remember the joys of a stable and feature frozen desktop environment only getting bugfix and polish. Also 13.2 comes with a new, light coloured desktop theme.
Of course openSUSE-Guide.Org has been updated for the 13.2 release.
And, as always, remember to join our community and help make 13.3 even better than 13.2!
Orchestrating Docker containers on openSUSE
A couple of weeks ago the 11th edition of SUSE’s hackweek took place. This year I decided to spend this time to look into the different orchestration and service discovery tools build around Docker.
In the beginning I looked into the kubernetes project. I found it really promising but AFAIK not yet ready to be used. It’s still in its early days and it’s in constant evolution. I will surely keep looking into it.
I also looked into other projects like consul and geard but then I focused on using etcd and fleet, two of the tools part of CoreOS.
I ended up creating a small testing environment that is capable of running a simple guestbook web application talking with a MongoDB database. Both the web application and the database are shipped as Docker images running on a small cluster.
The whole environment is created by Vagrant. That project proved to be also a nice excuse to play with this tool. I found Vagrant to be really useful.
You can find all the files and instructions required to reproduce my experiments inside of this repository on GitHub.
Happy hacking!
openSUSE.Asia Summit 2014
openSUSE.Asia Summit 2014 is the first openSUSE Summit in Asia, which aims to promote openSUSE and other free and open source software in the region (especially in colleges).
I am very pleasure to be one of the organize team members.
I want to mention Sunny's mail and thanks her and all staff again
---------From Sunny----------------------------------------
I would take this opportunity to thank the openSUSE.Asia Summit
organization team. Today, now the openSUSE.Asia summit has started,
I'm reminded of the journey we took to get here.
I can not forget our weekly meetings, which often lasted to midnight.
I can't forget 137 cards in trello for the preparation tracking.
And I can't forget hundredss of emails about the Summit in our mail
boxes.
When we were on the way to reach this summit, we encouraged and
supported each other. Even though we were tired, we never gave up,
because we did believe we would finally be here. It is my honor being
a member of such a great team!
There are 17 people in the organization team, I won't list everyone's
name because we are a team, and we couldn't have make any success
without each of us.
------------------------------------------------------------
Come from India / Beijing / Japan / Taiwan to welcome everyone come to openSUSE.Asia Summit.
Thanks our keynote speakers
* Richard Brown
* Ralf Flaxa
* 谷雷
Thanks all our speakers
We have lots of fun with session and workshop in these 2 days.
I have some sessions this year.
Long talk: FOSS & Education in Taiwan with Ezilla project
Short talk: Easy Install Nagios Server with openSUSE 13.1
And in All stars: Introduce openSUSE community in Taiwan
We have strong design team this year.
It still in my office right now :-)
I want to thank our sponsors
SUSE / HP / Firefox / CSDN / BLUG / owncloud / GNOME.Asia
Without our sponsors, we can't have such lovely summit.
The most important for me is
"We got lots of SMILE"
Thanks our great volunteers
Thanks all your contributions.
code churning and golang
The whole activity spanned for about 12 weeks roughly and we were able to build a very good evolutionary prototype. I was looking at the gitlab stats at the end of 12 weeks and found my personal log to be:
9752 lines added
7119 lines deleted
Even if we assume a 6 day workweek, it translates to about 135 lines of new go code added per day by a developer on an average. There have been very productive days, where I was able to add more than 400 lines of non-copy-paste code in a single day, that I ended up having to take rest the next day, to recover.
In the past, I have written a lot of C code. I have never felt this productive in C, largely due to the manual memory management (and the ensuing problems like double free, leaks, valgrinding etc.) and difficult concurrency (pthreads, locks, etc.)
It is kind of obvious that Go will naturally feel more productive, due to automatic memory management and concurrency friendly features (goroutines, channels, etc.), resulting in very less non-business-code.
However, I observed that there are two other non-intuitive reasons why Go lang was very productive (for me). These reasons do not appear big on their own. But in the overall development time, they were a big influence on my productivity. They are:
1) Static Binary Creation without complex, external build tools
Thanks to my openSUSE packaging experience, I have always taken up the responsibility to keep the sources of the project where I work as an engineer, in a properly and a packager-friendly build system. I like build friendly sources to an extent that, about an year ago, One of the first tasks that I did, when I moved to a team, was to port an old packaging system of hand-written makefiles and obsolete build systems with sources across tens of thousands of files and managed for about two decades, to CMake. IOW, I know about Linux packaging and its pains.With go, I was able to easily build the sources and get all the dependencies via a single `go get` command. Installing the binary on a test cluster, or in the AWS was merely a single command away. There was no need to wait for any complicated build setup, setting up dependencies or even waiting hours for a build to finish. There is no need to write complicated Makefiles, CMakeFiles, Configure files, build scripts etc.
Usage of the `go get` tool mandates developers to follow a certain discipline regarding installation/inclusion of libraries, binaries. Static binary generation helps avoid a tonne of deployment hassles. All these minor things, when we do a dozen or more builds in a day, add up to a very big productivity boost. It is not even that uncommon to do a dozen builds in a day, to aid testers, in the prototyping stage. Because of the elegance and simplicity of `go get`, the testers did not even have to wait on dedicated packagers or on developers to get the testbuilds. Even if you don't have dedicated testers, static binary generation, simplifies your test setup time.
2) Composition instead of Inheritance
This point is very difficult to explain, as it is more abstract, but is more influential than the previous. In the beginning, I was struggling to get Composition right. I ended up trying to organize my files based on an inheritance model (much like the [fs/< files>.c , fs/< ext>/I had to pause, unlearn a few things and think in a fresh perspective again to understand it. Composition is like Cycling. Once you get the hang of it, there is no falling down. I felt that the Composition based model has helped a lot more than any other feature of golang to improve my productivity.
With composition, the amount of code changes needed when you refactor code (which is very common in most freshly written code) is very very less than in a code, designed for inheritance. It is very hard to explain how this helps in simple English words. But I recommend you write code for yourself and appreciate this. In addition to easy refactoring, Composition tends to reduce boilerplate code substantially and makes diamond problem obsolete.
The Embedding of the Transport object in go lang's http Client object helped me understand Composition a lot clearer than any tutorial or book.
Conclusion
Because, I was able to write a lot of code fast, I was not too scared to shed code and start from scratch when needed. This explains the about 7k deletions of code.goimports and vim-go also helped a lot to get some IDE like features, all of which should thank gofmt in return.
Have you felt any other reason that made you feel a high-level of code churning can be achieved in Go ?
Dice - A light weight build service
It was fun and Marcus code was very easy to understand, very well structured and with comprehensive tests.
Dice is a simple build service for KIWI images using virtual instances controlled by vagrant or a directly contacted build machine. It can be used to fire up build jobs on e.g public cloud instances.
What that means is that you can do:
>dice build myimage
and that will either:
1- start a virtual machine on your workstation/laptop and build your image IN that virtual machine
2- connect to a virtual machine on the cloud (i.e. google cloud) and build your image IN that cloud virtual machine
And why all the trouble? the reasons:
1- setting up an environment for building images on your laptop/workstation can be sometimes paintful
2- running multiple builds on your laptop/workstation will make your host performance get low. Builds take time, thus you normally are doing something else meanwhile, and running the build on the cloud can be very good so that you can use your resources for something else
3- security: building an image implies running custom scripts. If you have done this scripts, fine, but if not, better not run it on your laptop/ws.
4- availability: having a build service on the cloud, makes it available to others that won't have to invest time on setting it up
During those 2 days, I just implemented the ssh command as:
> dice ssh myimage
which will open an ssh connection to the build node, either virtual machine on you laptop/ws or in the cloud, so that you can easily debug when a build fails.
II Security on the nework Congress
This was held very close from where I live now and I was invited to give a speach there, which I happily did.
I explained the timeline of CVE-2014-081 (see my previous post on it).
There were about 300 people registered and was a very interesting event with very interesting talks on security.
I was also very happy to meet a friend from my home town.
Overall, it was fun and worth it.
Thanks to the organizers!
New toy
I got a new toy. It’s a WASD keyboard with Cherry MX Clear switches. The picture doesn’t do it justice; maybe I should’ve gotten a new camera instead… I guess it’ll have to wait.
Mechanical-switch keyboards are pricey, but since I spend more than 2000 hours a year in front of a keyboard, it’s not a bad investment. Or so I’m telling myself. Anyway, it’s a big step up from the rubber dome one I’ve been using for the past couple of years. The key travel is longer, and it’s nice to have proper tactile feedback. Since the Clear switches have stiff springs, I can also rest my fingers on the keys when daydreamingthinking. It has anti-slip pads underneath, so it stays put, and it doesn’t bounce or rattle at all.
Until our last move, I clung to an older, clicky keyboard (I don’t remember which brand — I thought it was Key Tronic, but I’ve a hard time finding any clicky keyboards of theirs at the moment), worried that the future held rubber dome and chiclets only — but today, there are lots of options if you look around. I guess we have mostly gamers and aficionados to thank for that. So thank you, gamers and aficionados.
I did plenty of research beforehand, but WASD finally drew me in with this little detail: They have some very well thought-out editable layout templates for SodipodiInkscape. Good taste in software there.
Discourse/README.SUSE
README.SUSE
So it seems you installed the discourse package that we provide for openSUSE/SUSE.
Preparing PostgreSQL
$ zypper in postgresql-server postgresql-server
$ su - postgres
$ createuser -P discourse
$ createdb -O discourse discourse
Add the required postgresql extensions to the DB. We extract those at build time from the migrations. If you run migrations with a normal postgresql user, you can not add extensions during the migrations. That’s why we add them here.