Skip to main content

a silhouette of a person's head and shoulders, used as a default avatar

Karma version 1 released


The first version of Karma plugin is out on Connect. Users can add the karma widget from the widget gallery, it might take a minute to load, because karma updates if you view your widget the first time or every hour after that.


Also, Karma fetches your activities on twitter, planet openSUSE and Novell's Bugzilla. Starting from now, Karma rewards you for your previous 5 tweets, and each of your posts that appear on planet openSUSE in the last 3-4 days and then onwards and all of your resolved bugs on Bugzilla.


There are certain things that you might notice when using the plugin, first as I wrote it might take a minute to load if karma was updated more than an hour ago. Then, only your previous 5 tweets are rewarded for, so If you tweeted about opensuse way back in the past, I'm afraid it might not be counted.   Also do not forget to use the hashtag (#openSUSE) for tweets to be rewarded, and its case insensitive :D


Those of you who have aggregated their blog feeds on Planet OpenSUSE but haven't mentioned their blog url on their Connect profile, will not be rewarded, same goes for Lizards blog. Though rectifying this is in the pipeline, but not now.


Please check it out, let me know if you like it or even if you dislike it completely, I think I can do something about that. :)

the avatar of Stephen Shaw
a silhouette of a person's head and shoulders, used as a default avatar

Karma update on Widget view


Weekly Report (14 june - 21 june)

In my last report I mentioned about having separate developer and marketing Karma, as I had problems comparing tweeting with Bug fixes or commits. Well, I have accomplished that. We have separate Developer karma for score achieved on fixing bugs or making commits on OBS, Marketing karma for score achieved on tweeting  and posting on Planet openSUSE. Appropriate badges are awarded on securing a higher developer or marketing karma.


During this time  Michal my mentor, tried deploying Karma on the Connect website, but the karma cron script would not run to completion for all Connect users due to certain limits on server or gateway or both. So the idea was to reorder the query and run cron script more number of times with less users each time.


Within the cron script, I save the time of the last run as metadata belonging to a user entity. Then use this metadata to order the query and get 5 users who have been the longest without updating. Cron script now runs every five minutes for 5 users who have remained longest without updating.


This would work with users who already have the karma last update time saved in the database somewhere, so the cron script also assigns this metadata to all users to whom it has not been assigned yet.

 
Then I also worked out the updation of karma on widget view (this is not a part of the cron script). If karma was updated more than one hour ago then karma details are updated on widget view. Assuming Connect has 2000  - 3000 users it would take 33 - 50 hours to update for all users and come back to the first one, if we relied only on the cron script.


Hence, this suffices for situations when karma has not been updated in time by the cron script.

a silhouette of a person's head and shoulders, used as a default avatar

Port Forwarding with xinetd

In some network environments, where for example administration lans or some private lans are deployed, it might still be necessary to access a specific port of a machine inside that lan from the outside. Commonly, you would have to access a jump host and from there you would be able to reach the respective machine.

In our case, we had to reach the management port of a switch in a private lan. For example:

  • the private has the IP address range 192.168.10.0/24
  • the switch is configured with 192.168.10.254 and its management port is 80
  • the jump host with access to both networks has the external address 10.10.10.1

To access the switch directly at address 10.10.10.1 with port 81, you can configure xinetd on the jump host with the following configuration:

# cat /etc/xinetd.d/http-switch
service http-switch
{
 disable = no
 type = UNLISTED
 socket_type = stream
 protocol = tcp
 wait = no
 redirect = 192.168.10.254 80
 bind = 10.10.10.1
 port = 81
 user = nobody
}

After reloading (or starting if not yet done so) xinetd, you can reach the switch by pointing your browser to http://10.10.10.1:81:

chkconfig xinetd on
rcxinetd restart

The same principle can also be used when forwarding e.g. ssh ports of machines.

the avatar of Klaas Freitag

Hand in Hand

as you might know, ownCloud uses the Open Build Service (short OBS) to produce and distribute the binary packages for the various distributions we want to support.

The OBS is a great system as it does not only build for various Linuxes but also lets the users download the binary packages utilizing a huge mirroring infrastructure. All for you, all for the good of free software.

And there is even more: OBS offers a nice download page which can either be embedded into a projects webpage or be linked from it. Depending on the settings of the OBS project, for example the number of Linuxes it builds for, the page is adopted automatically. So you never again have to deal with lots of download links to the projects repository downloads. See the ownCloud Client Package download page as an living example.

Now the page had a shortcoming for apt based distributions. I became aware of it as the problem as well as the solution to it was nicely pointed out by this blog: Apt wants to have the key before it trusts the download source. OBS generates the key but its not obvious how to import.

This morning I told one of the brave OBS developers to the blog post and already now the solution is online. From now on, the download page also shows the exact command line to import the key. Isn’t that great how quickly things become better if a couple of people do a little bit work together?

Thanks a lot, guys, really cool…

a silhouette of a person's head and shoulders, used as a default avatar

Announce: C#/VB.NET/PowerShell API to write LDTP (GUI Automation) tests


I'm happy to announce we now have C# API for LDTP. Tested the API set with VB.NET and PowerShell.

Get latest LDTP binary from here

Credit: John Yingjun Li, who have done the most of work creating C# client, verifying with Linux LDTP, creating VB.NET test app.

API's tested against Cobra (Windows LDTP) and LDTP (Linux version, remotely though). Include Ldtp.dll and CookComputing.XmlRpcV2.dll into your project as dependency.

Check C# client and example source.

the avatar of Andres Silva

openSUSE and Identity

Ever since the conception of graphical environments for the computer, designers have had to make specific decisions about the way we interact with elements on a screen. However, to say that "designers" made all the decisions on how we interact with the computer is somewhat far fetched. 

There are many other factors that make up our computer interactions. In a sense, the word "designers" also involves people who are not directly related to the graphical world. Those could be - a sales manager who also decides what elements we see on the computer screen; a contracted hardware company that would like you to have a certain software on by default; and many others may also have a part in the user interface designing process. The computer GUI has a varied influence in its identity.


The multi-influence, or “multi-graphical input” for devicces’ GUI has come under particular focus in recent years. Mass adoption of mobile devices has spread the graphical competition to all new heights. It has become much harder for companies and their products to stand out on the current market, or to make a difference. Differentiation is the call for each of them. Making their devices different graphically has called for stronger branding, and each of the market players now steeres in different direction. The objective being - attracting new client and retaining the existing ones. The drive for graphical differentiation makes it clear that stringer branding will help them sing a different song.

This changes have also made it into many of our Linux environments. KDE, for example, decided to make a radical jump with KDE 4. While recently Gnome released their 3rd series other environments, prefer to keep the same idea of what a GUI should look like. 


Currently Linux, as a worldwide community, faces strong fragmentation. Not all of us use KDE, or Gnome, or a graphical interface at all. At the end of the day these communities are the ones creating new software, new widgets, and new graphics. Eventually these fragmentation or macro-collaboration environment is unable to achieve "collective individuality." This means that because of the different influences that happen in a Linux environment, collectively we cannot achieve a strong branding and differentiation. We cannot stand out because all of us want to stand out. Our software or contributions speak the language and mind of its creator, except in a Linux environment, anyone can be a creator.


These changes raise a question from our own group of contributors. Is openSUSE at the height of this weave of stylistic changes? This question is not about code or software integration, but exclusively about the end user experience. Reasoning carefully, the answer would be "partially." openSUSE has not taken full advantage of the branding capabilities provided by both KDE 4 and Gnome 3. This trend is more so surprising considering that openSUSE is the first to integrate and use many new Linux technologies through its unique OBS service, yet brand-wise we remain stagnant. Early adoption and fast integration in our distribution makes it harder to work on and maintain distribution specific styling.









In the recent years we have become quite passive in developing our own identity, other than using green as a base color openSUSE. Subtle color changes however do little with styling KDE or Gnome for the releases.


In earlier years this was a much stronger effort. Back then both KDE and Gnome had their own distribution specific themes within openSUSE. But recent changes in both environments have made it harder to keep up with distribution styling, and we have fallen behind. Even now openSUSE’s artwork team has not diminished in its efforts to work on styling, however the technical aspects of styling KDE and Gnome has become much harder to keep up with.


There are no simple way of creating interfaces for  KDE to create a window style without knowing C++, for example. We have to rely on the technical knowledge of developers with strong knowledge and understanding of C++and GTK/Qt core technologies. In gnome changes with GTK 3 have been taxing on developers since they now need to migrate their themes to work with the new widget styles present in GTK 3. For openSUSE, this all means that is has become harder to create our own styling therefore we adopt KDE and Gnome’s default styling.


Adopting the defaults provided by KDE and Gnome will eventually move openSUSE to a state of visual stagnation. Not because these integrated window environments will stop moving forward with GUI developments on their own, but simply because we will have traded our visual identity to their definition of a default. While the rest of the technology world moves ahead with change, openSUSE will remain unnoticed for its outdated visuals.


Styling matters more than what we give it credit for. Styling is the first impression any users gets as they install our distribution. Styling can be provocative and generate interest, contribution and a larger reach with users. openSUSE will collectively speak to a wider audience given its “new suit.” openSUSE’s identity will speak for the project as people download the ISO. The unknown new user that is willing to try Linux for the first time will be impressed with the power of openSUSE and the cleanness of its desktop, the boldness of our green geecko will secure another happy user and a possible contributor. Even our current users will see how their distribution of choice changes to fit their daily work routine.


Recent work on styling from openSUSE’s artwork team has yielded great results for the distribution. With the help of a few contributors to the artwork team, we have been able to include new wallpapers, splash screens, boot screens, marketing materials and a few other things to the distribution. However, this is no different than it has been for a few years. We style the same elements with every release. To have a bigger effect and support with the community, we launched image contests, updated wiki pages, pushed sources to git, created new scripts for the automated wallpaper sizing, and have integrated more contributors than in previous years. Our channel user base is looking to expand.


As a result of this push for work there has been great integration in the team. We have been able to identify each other's strengths and have used them smartly as we integrate artwork into the distribution. Good attitude, willingness and enthusiasm to participate has been our idea since we reorganized ourselves. A sense of belonging and an akin interest in making opensuse a sleek distribution graphically is our intention. Getting help and comments from our team is easier than ever.

Through our team's interaction, we have determined a desire to make our distribution a stronger player in the linux graphical environment. We must jump into the wagon where the trend is going. We cannot be passive about our identity anymore. This is not to say that we want to be graphically similar to others and borrow their styles, but rather our aim to have openSUSE be recognized beyond the color green and the geecko. We imagine a time where icons, window styles, colors, wallpapers, desktop organization, specific desktop widgets are all integrated with a strong presence in the Linux world.


If we stay the same we will remain there as well for prospective users. We need to make a strong impressions to those people who are deciding between Windows, Mac and Linux. Those who hear of the power that Linux has and through the power of each community. We have the resources, now we need to move the mountains in order to achieve these goals.


We would also be much more ahead in styling than most. Take for example Ubuntu. They have created a style of their own with their human and name coded releases. They have persisted and perfected their styling beyond even what most would think or like. We do not mean to have this type of interface for openSUSE but definitively make a stronger impression much like Ubuntu has. 

Additionally, we would provide a much less attacked interface by staying within the regular styling standards that the majority of users have on their desktop. We don’t mean to be radical with changes, but include our community in speaking about what they think should be allowed as a stylistic change in the distribution. We understand that the behind-the-doors changes are not particularly supported and also having the input of our community will add for great thinking and clever organization on the desktop. We could well be the most cooperative distribution when it comes to style.

the avatar of Jeffrey Stedfast
the avatar of Klaas Freitag

ownCloud BOF at Akademy 2012

Akademy 2012 isn’t far any more and I just registered for a BOF at this years Akademy in Tallin. It will take place in Room 419 on monday, July 2nd, 2012 at 10:30.

Subject of the BOF will be the integration between KDE and ownCloud. As onwCloud originated from the KDE project we should meet and think together again how we can provide useful integration for the users combining the power of both technologies.

After a short overview of where the ownCloud project is going and what the recent achievements are (if participants are interested) I think we should concentrate on the technical level.

There are a couple of rough ideas already how we can integrate on a technical level, such as

  • Integration of the ownCloud data storage in the KDE user experience.
  • KDE features for the ownCloud Desktop Client like KWallet integration or KDE SSL certificate management.
  • Synchronisation of PIM data like contacts, addresses, bookmarks or RSS feeds
  • a syncing API for application data to be synced in KDE applications.
  • Syncing of KDE application configurations.
  • Plasma integration of ownCloud/syncing client.

I am sure there will be more we can come up with. Let me know upfront if you want me to put it on the list or even better show up at the BOF in person.