Building for your version of openSUSE in 5 simple steps!

Today I bumped into a blog about dfc, a more fancy version of the df command. There were instructions on installation for Arch and an older Ubuntu version - a link to software.opensuse.org/package/dfc wasn't there but easily found.

There were packages, thanks to the awesome Open Build Service packagers. Unfortunately, it wasn't build for 12.3 yet. Now what? Luckily, this is what OBS makes easier than pie, let me show you how you can build this package for YOUR openSUSE version without ANY technical knowledge!



Step one, you click on the repository name, "home:tcpip4000". You now go to the OBS page where Juan "tcpip4000" Danza builds dfc. In order to be able to make changes, we need to branch dfc into our own home (you need to log in on OBS first to do this).



Step two, you click on "Branch Package" and say OK to the question if you're sure about this. Now, you've got dfc in your own home and the Open Build Service will immediately begin building it. However, it still just builds for the operating systems tcpip4000 had defined - we have to add a new one!



Step three, click on "repositories" and change them. You'll see on that page you first have to go to the project that dfc is a part off, as you can only enable or disable building for a package, not the build targets themselves. Click on the branch ("home:jospoortvliet:branches:home:tcpip4000") and under "Repositories" there, you pick "Add repositories".





Step 4, you can pick what you want and hit the button on the bottom of the page to add them. By default, packages are build but not 'published' in a repository for easy download. You can change that by hovering over the "Publish Flag" section and enabling the publishing.



Step 5, go back to the dfc package which will be build by the Open Build Service and then published in the repository. You can use the little refresh button to check for the status - and once it is build successfully, click the download button and call it a success!





Now, enjoy your new package and have a lot of fun!

If you want dfc for openSUSE 12.3 and Factory, check here. Of course, not all packages will build successfully for a newer or older version of openSUSE: you might have to make changes to the spec file. That is where things get more complicated and you'll need the documentation on packaging and help on IRC. Also, if you're up for it, this can all be done even faster from the command prompt with a few simple commands. But that's a lesson for another day ;-)


To add one more DFC tip: if you edit the .bashrc file in your home folder, you can use this command by default. I have this in my bashrc:
alias df='df -h' # human-readable sizes
[ -f /usr/bin/dfc ] && alias df='dfc -T' # use dfc if there for prettier df info and show filesystems

This will ensure that if you have dfc installed, it uses it by default (the [ -f ] thing checks for that) and if you don't have it, df -h will show the output in human-friendly sizes :D

On Innovation, Free Software, NIH, Geary, Trojita and KDE PIM

I argue that if Free Software wants to get anywhere, it needs a culture of 'collaboration first'. In most areas, we have that. In some, we don't - and that is hurting. The desktop is probably a prime example of that.

Rob Boudreau wrote an opinion piece about Personal Information Management (PIM) and the future. He concludes that 2013 has different requirements from PIM than 1995, and:

"KDE PIM seems to be the only FOSS project working on technology that will eventually go beyond just the PIM itself"

I think reality agrees with him. Mobile devices are cleverly integrating chat, email, social media and phone in one. Contacts have details on all of these and show the latest tweet or Facebook message of that person as status. Why doesn't the desktop do this? Well, it does, but only by putting your data on corporate servers, accessible though web browsers: Facebook, Google, Microsoft, ...

The Linux Desktop has a mission here: help keep user data out of the greedy hands of Google, Facebook and Microsofts! That can only be done by building on the shoulders of giants, not by re-inventing the wheel out of sheer arrogance. Let me explain what I mean.

Collaboration

10 years ago I often presented to people new to Free Software and how we work. I would explain the benefits of Open Source so:

"Imagine you thought of the best New Idea for word processing. From now on, documents will almost write themselves. But you first have to embark on the huge journey to write a full word processor. Three years later, your amazing application does not get anywhere as it can't open MS Word files."

"Imagine instead you added your amazing feature to an existing word processor. The discussion with the experienced word processor developers even resulted in a better result!"

Being able to stand on the shoulders of giants is an important benefit from collaboration in Free Software. We do have competing projects but note that most successful forks and rewrites were started due to a lack of collaboration! A recent example is LibreOffice. Often people from the 'original' project join or even start the fork or rewrite. Wayland is build by the Xorg team and the MySQL fork MariaDB is led by the founder of MySQL!

The Linux kernel is another great example. Google, for example, is putting in enormous resources in getting their technologies back into the kernel. After a period of forking for the benefit of speed and efficiency, they figured out that in the long run, it actually is more efficient to not fork and put in the extra effort in collaboration.

Collaboration-by-default is not a given. Aaron Seigo said about KDE:

"The open nature of the community has purged the “not invented here” syndrome from our ranks"

Yes, the KDE community has a strong tradition of re-using efforts and building on the shoulders of giants. And questioning those who don't! But such a culture took years to build as there is plenty reason to NOT collaborate.

Reasons for not collaborating

Failing forks or duplicating projects are often based on personal conflicts or a dislike for certain toolkits, languages or technical choices. And there is much starting from scratch because developers just focus on their own problem or want to learn something new.. While I would argue that you probably learn more working with experienced, competent people, and you might get more done, too, it is not hard to understand these reasons.

Then, there is psychology. Most people think they are smarter than average and programmers are no different (sometimes expressed as "what others do is easy")... Given the bell-curve followed by the distribution of intelligence, this clearly is one of the many fallacies our brain saddles us with. Even companies are affected. Google, working to get their features into the upstream kernel, discovered that not all the intelligent people in the world work for them and there is lots of room for improvements in what their team came up with.

More than one mail client

I argue that this last reason leads to more duplication of effort than healthy in the area of mail clients. Recently, Yorba pushed to get funding for Geary, another 'new approach to mail'. And there is Trojita, also providing a great IMAP client. Both projects were started in the last couple of years and seem to be re-inventing the wheel -- twice. As you probably saw many prominent developers giving a hard time to a company insisting upon writing another display server, I hope you understand how misguided I think this is. Yorba said they decided to write a new email client to keep things simple and fast and due to the complexity of other mail clients... I described the rationale and wrongness of this "let's write a new mail client" approach in a comment on LWN a while ago. In short, I'm betting that the reasons behind it boil down to the previously mentioned combination of over-estimating oneself and underestimating the problem. In the case of email probably a lack of ambition and forward-thinking as well. Just email doesn't cut it in 2013, certainly not 5 years from now.

Bringing conversation-view to email is an awesome idea - and can probably be done through a Google Summer of Code project within an existing client. Writing an entirely new email experience needs a bit more effort of course, but writing the entire underlying infrastructure too - that is just a sodding waste of time, pardon my French. Good to see Trojita at least has joined the KDE community and is working with KDE PIM! How about you, Geary?

More than one conference

I've always been a big proponent of the Desktop Summits and I do indeed think that it shows both arrogance and a lack of big-picture thinking that these don't happen anymore. I'm glad that the KDE board, including Agustin (who organized the first Desktop Summit) managed to kick off a "freedesktop summit" at the SUSE offices. I'm also glad that some people who DO see the benefit of collaboration participated there - even if their communities don't (yet) understand that it is worth the investment.

What we need

We need a culture where we are critical of people who don't try to work together or are unwilling to put in effort to collaborate. Free Software depends on collaboration and not working together is just counterproductive. So I'd like to ask all readers to support collaboration: talk about collaboration, share the tales of success. And if somebody decides to write an app from scratch, or is writing an application doing the same thing another does - question them, ask why they go it alone, why not collaborate. It is totally OK to be critical of forks and anti-collaborative behavior. You don't have to beat anyone up, but at least making them think about it is a good thing. And if you're a developer: integrate technologies, build re-usable libraries. And remember that the shoulders YOU are standing on can be made stronger for future generations of Libre developers! Just dumping disconnected code is NOT a contribution to Free Software, contrary to what some folks seem to think.

I'd also like to ask people to support KDE PIM: if we want to have a shot at keeping our data out of greedy corporate hands and if we want to ever get onto the corporate desktop, Akonadi is the only architecture that really has a shot. Instead of writing new wheels, let's improve this one together! Yes, KDE PIM needs UI work. Then why not do that? Writing a new mail client makes total sense - if you build it on a proper infrastructure. The KDE PIM team is greatly looking forward to help people who want to write new mail, RSS, Facebook or contact management applications. Skills required are mostly related to motivation and the willingness to ask questions and get help - otherwise, javascript coding skills will probably get you pretty far as it makes all the sense in the world to write these new UI's in QML.

Concluding

I'm happy to concede that things are not black and white. I'm sure nobody can fully judge neither Geary nor Trojita or all aspects of the Desktop Summit. Mea culpa for any wrongness. But please take the lesson to heart: there is great value in collaboration. And getting these benefits means putting in 'extra' efforts, yes, it can cost you something in the short run - that is the whole point of long-term vs short-term thinking. So, next time somebody argues that 'we can go faster if we do it alone', tell them that most smart people do NOT work for you and problems are always simple when they're not (yet) yours. Or just remind them that once upon a time, people thought volunteers could never write a encyclopedia. It is the 21st century and collaboration is what sets apart winners from losers.

Take care!

Why should you participate in GSOC as mentor?

When deciding about participation in the Google Summer of Code program you think about the opportunities of getting new people involved or code written versus the time they have to put into mentoring and evaluating. But there are other, often overlooked advantages to participating in GSOC and I'd like to point a few of those out.

GSOC
Google started the hugely successful Google Summer of Code project in 2005 to get students exposed to 'real developers' and open source. Since then, it has allowed projects to mentor thousands of students who were enabled to work on Free Software full-time thanks to the payments by Google. Conceived of by Sergey Brin and Larry Page, the project was also supposed to bring fun, excitement and innovation to the open source community. Each year, thousands of students send in proposals and Google allows the most promising of them to execute their ideas.

In practice
Projects put in a lot of effort mentoring these students, hoping they will stay around after the project or get some coding work done which otherwise might not have happened. This works out to varying degrees - not all students stay, not all code gets merged, and some mentors feel that they put in more effort than it is worth.

Serendipity
While I can not judge the cost-benefit ratio for each project, I'd like to point out that there is a factor you should include in your calculation: serendipity. If you're unfamiliar with the term: it means "happy accident". Simply put, it is the positive outcome of something you were doing for entirely different reasons.

GSOC has benefits beyond 'getting people involved' and 'getting code written'.  Here are a few of these:

• GSOC creates a lot of positive attention around all projects that are involved. The vast majority of this is positive, fun news about features, getting involved in the project and more.
• The students also create a flurry of activity. They ask questions, get answers, write proposals, push people to help them. Activity leads to engagement and for those already involved it is often nice to see interest in the project and stuff happening.
• You also create long-lasting fans with the mentoring of students. They are 18-25, a very formative time in the life of a person. Most will look back with good feelings to their time with your project, even after 'life' has taken them other places. The value of this 'social capital' is hard to judge. But I am sure you understand what it could mean if one of your students makes it to CTO of a big company and they have a chance to do something related to your project!
• Your project learns from the GSOC experience. People learn individually, but projects as a whole learn too. This is not as ephemeral as it might seem: the way your project works is build upon many lessons-learned. GSOC makes your community adapt to new requirements of coordination and organization - learning!
• Sitting down together, thinking about ideas and discussing them is useful. You find out what your fellow team members think about ideas, what you could work on in the future - and perhaps you come up with The Next Big Thing™ ;-)
• Last but not least, there are networking opportunities and collaboration with other organisations. Some of the mentors and students travel to the GSOC meetups around the world, having an opportunity to discuss mentoring and getting new people involved with other teams. This is of course especially true when you collaborate with several communities together, like +openSUSE does this year with +ownCloud, Hedgewars and Oyranos.

I started this blog because I wanted to remind our students that is time to start creating proposals for Google Summer of Code 2013. But I'm hoping the above is also inspiring for mentors - there is still time to get involved!

So what to do?
For students looking for a project, I integrated the openSUSE/Hedgewars/ownCloud/Oyranos ideas I understood (that's a subset...) in the article so readers would get a glimpse of what GSOC for openSUSE has in store. It is cool stuff: integrating maps in apps in ownCloud, fcitx in wayland, comment support in OBS and much more.

Meanwhile, of course, there are GSOC idea pages all over. I checked out the KDE ideas page too - being the largest GSOC project in the last few years, I did expect quite some nice stuff. Oh boy... From web applications and library work to Amarok, Digikam and Plasma, there is a huge number of really cool ideas.

openSUSE and KDE are just two of the many organizations involved in GSOC. If you're a student, think about applying. And if you're a current contributor, think about how you could help your project by helping a student!

Dear KDE Community!

Dear KDE Community,

meet the mailing list where you can now talk about non-technical topics relevant to our community: kde-community. From a debate about our next conference to discussing our collaboration with other organizations and our goals as KDE community, this list is for anything which does not fit on the KDE development lists.

The goals are described clear enough:

The purpose of the mailing list is to provide a place for non-technical information and discussions which are relevant to the KDE community as a whole. All people who consider themselves to be part of the KDE community are invited to join. Conversations on the mailing list are respectful, considerate, polite and constructive following our KDE Code of Conduct.

The list collects announcements, information and results from discussions in other places and offers a place to get feedback on non-technical questions or plans of relevance for the whole KDE community.

As the 'collects announcements, ...' part already hints at, we expect people to try and make a habit of summarizing discussions which do NOT take place in public on this list once a conclusion is reached. This should be the central place for KDE governance debate.

You can find the list and subscribe here.

History lesson

Summer last year Cornelius wrote a blog about setting up a kde-community mailing list. It had been discussed on the KDE e.V. list that it doesn't make much sense that we have no public place to discuss governance related things in KDE.

Most of these discussions take place on the private KDE e.V. mailing list. Mirko Boehm proposed to simply open that list: what is discussed there is relevant to the whole KDE community. While there was agreement on the principle of opening up, there are things which are discussed there that probably should not be open. They are few and far between but some discussions about financial or personal matters do benefit from a less public place. Some argued that public discussions can also harm our public profile and it came up that bikeshedding could get even worse.

An alternative was proposed by Jos vd Oever: create a new list and put discussions there, unless there is a strong need of keeping them private.

After this, however, the discussion kind'a died out (I am summarizing more than a handful of mails here...). The subject came up at the e.V. board meeting in Berlin and we agreed that there's no good reason to Just Do It™. If nobody likes the idea the list will remain empty. Natural Selection FTW! I went ahead, asked our Amazing Admins to set me up, configured it and made Cornelius and myself admins who will exact our vengeance on everybody we disagree with who misbehaves.

So that's the story. The result is the KDE Community mailing list on the KDE servers. Is it official? What, you active in KDE and you don't know how nonsensical that question is? As always, the list will have to prove itself... I can only ask: please subscribe and bring your non-technical questions, comments, reminders and proposals to this list. We'll yell at the folks on the internal e.V. list if they bring things there which should be public.

And don't forget: if you want to talk to each other in person, this is where you do it. Go and book ;-)

Looking forward to your hugs at Akademy!

Klyde coolness update

I've heard Will Stephenson, Klaas Freitag and Frank Karlitschek talk about a lighter and/or easier KDE based desktop forever. And while I shared the ambition, implementing it is always easier said than done.

So when Will asked me to join his Klyde Hackweek project, I thought - awesomeness, let's try and finally move something forward! And that happened, we had lots of fun and I learned some real packaging tricks. I'll bore you with epic details at a later time ;-)

We realize the idea of Klyde and what we aim to do is a tad vague so Will and I had a long chat yesterday and came up with some more details about our focus.

1. Modular for everybody

The first goal is to make everything more modular. The openSUSE KDE team did a huge effor here, simplifying dependencies so you can have a Plasma Desktop without most applets, Activities, Nepomuk or Akonadi. Of course, that means you give up on good and useful functionality but reality is that we don't always need everything. This way the functionality is optional and this will hopefully become the default packaging state for openSUSE. What you don't use will not add menu items, widgets and memory usage to your system.

By default, a 'Klyde' desktop comes with none of the above-mentioned things and only a minimum of applications and applets. But upon installation of Activities the widget will be added to your panel and Akonadi will fire up the first time you start up KMail or Akregator!

2. Low footprint if you want

We know that 'lightweight' is not easy to define and it is hard to do scientific measurements of memory usage and all that.

Currently, the Klyde settings have some obvious things (disabling animations, disabling some services etcetera) and lots of temporary choices (plastique as widget style for example). We WANT to make informed choices here and input from developers on what is faster (even if that means loosing some functionality or eyecandy) is very much welcome. And we realize work will be needed: we would greatly welcome help creating a fast and efficient widget style, for example.

3. Simple by default

systemsettings simplified.

Systemsettings exposes about 80 different modules to the user. Some of these you'll (almost) never use. And many which, from an user point of view, belong in one place (like theming) are split over several categories due to technical implementation details. It is noticeable that this was designed from the technology up, not from the user requirements down. I spend a big part of my hackweek figuring out how these categories are populated and the modules are shown, then creating an alternative tree with only about 35 modules. Will made a patch to allow systemsettings to either show the basic or the full set of KCM's.

This is an example of what we mean by simple, although we're not done yet. Ideally, these and other improvements will go upstream and we intend to put work into that.

Note that this simplification, in no way, can be scientific. Of course 30 KCM modules is more 'simple' than 80 but it is very much a matter of taste to decide which ones need to be there and which ones don't. That's why we want to put effort in having our cake and eating it too: creating a proper theming KCM might allow us to get rid of a whole raft of theming-related KCM's, for example. Yup, we're still KDE people... But in other places, we are willing to make hard choices based on common sense, research and simply our taste. Unless a designer can convince us he/she Is Right™ we reserve the right to make bad decisions.

Feedback?

We're open for feedback and would love to hear input. Please remember that we're trying to get stuff done so if you have input, put in the effort to make it useful. Have mockups, refer to what others do or scientific facts. Remember that we are not trying to create a desktop for experienced computer users and tinkerers: they can easily morph the normal Plasma Desktop into what they want. It's what I do myself, its what the vast majority of people who read this do.

Instead we aim for a wide cross-section of people who don't want to put in the cognitive effort to understand abstract stuff like virtual desktops or activities. If you understand and use these things to be more productive (which I do myself, by the way), you're not our target audience.

If you want to help out, join the #opensuse-kde channel on freenode and check out our trello board.

Enough talk

Enough talk? Wanna try it? Yeah, it ain't perfect yet, but I've created an initial Studio image and published it in the Gallery. It can be installed, if you insist, but this is a beginning of a work in progress: it will eat babies whenever it can.

Click to go to SUSE Studio for the testing appliance.

About packages and a repo, this isn't easy as you would either have to remove packages by hand or start with a very basic system with only X for this to work. We're looking for a solution there ;-)

EDIT: User and root password for the appliance are the SUSE Studio default 'linux'.

Have fun with it ;-)

Klyde in a VM.

Taking stuff apart

Last Saturday, I took apart an old and broken laptop of mine: a Sony Vaio VGN-TZ31XN. That was once a top of the line executive laptop. I bought it in 2009 when the model had just been discontinued and superseded by a new one, so it wasn't too expensive.

The laptop had an 11" 1366x768 screen, a 1.2 ghz Core2duo, 2GB of ram and 120 GB hard drive. The reason I paid 1000 Euro for such lowly specs is that it had a weight of 1.25 kg, doing about 6 hours on a battery charge.

Impressive piece of tech

I've been wanting a new laptop since I started to bump into performance issues during 2011. 2 GB of ram is not sufficient in a time of HTML5 - there are web pages which eat several hundreds mbs of ram. And unfortunately the Linux desktop isn't getting lighter either (it's part of why I decided to help Will and Klaas with Klyde for hackweek). And I've been doing some light video editing lately as well as more image editing. So when the screen of my laptop finally gave beginning of last year, I simply ordered my new Samsung Series 9. That Series 9 was actually more expensive than the Sony (prices have gone down since then). It is a step forward, but it is sad that it took the IT world over 5 years to finally eclipse what Sony did in 2007. And not even on every level - my Sony included a DVD burner, 3-antenna wifi, TWO card readers, mini-PCI-express, 120 GB spinning rust, FULL ethernet and VGA ports, Firewire and a removable battery in barely 100 gram more!

Opening up

When you open up the Sony, it becomes apparent how they managed to cram so much functionality (essentially everything a 'normal' laptop offers) in such a thin enclosure: they must have worked with the assumption of an unlimited budget. Seriously, it is clear why this laptop was over 2K: the target user group seemed to be entirely unwilling to compromise on features. This thing is far more complicated inside than modern ultrabooks. My Samsung S9 is mostly battery inside: it has a single, laptop-wide motherboard with 2 boards (wifi and mSATA) attached to it.

Nothing compared to the Sony: taking it apart reveals a square motherboard, a battery-power related board inside a casing, wifi board (the usual), blue-tooth board (tiny), audio board (2 chips & capacitors, audio in/out, 2 speakers, microphone all attached), 2xUSB+card reader board, touchpad board (the touchpad itself also has logic, of course), quick function keys board, 2 more small board I can't identify. Then the DVD burner has its own internal boards (2) and one on the outside, apparently to interface between the mobo and the dvd burner. Oh, and of course, memory is separate and can be replaced. The webcam also has its own 4 cm long/half wide/double sided board.

Crazy, huh? All that is connected via a myriad of flat cables, tied with tape and thermal pads everywhere, and of course screwed. Total nr of screws in this laptop is 81 and I'm sure I missed a few. Here's me betting the Series 9 doesn't even have half of that.

Considering the progress of technology, I would say that the Sony Vaio VGN-TZ31XN is far more a marvel of technology then the Series 9. Yes, the Series 9 is awesome: 1.15 kg, thinner, 13.3" screen with a higher resolution, faster CPU etcetera. Much quieter, too. But considering it is about 5 years newer it just makes the work by the Sony engineers around 2007 all the more impressive.

BTW, Sony was proud of the use of 'carbon fibre', something I've never taken serious: the laptop felt plastic all over. But after taking the entire thing apart, the top and bottom both turned out to be made of a VERY sturdy, extremely thin slap of what I can only guess is that famous Carbon Fibre. Yeah, most of the laptop is plastic, but they saved weight for screen and bottom, at least. It's just not noticeable from the outside...

And I enjoyed the breaking up of everything. I spend quite some time looking at the more intricate parts - the DVD drive laser mechanism is quite intriguing and trying to figure out what the chips on all the little boards do was also interesting. Of course, almost everything is broken and I wouldn't be able to put this thing back if my life depended on it!

What's left

Ossi, who paid us a surprise-visit yesterday, almost took the mother board as the power converters on it were apparently interesting, but decided he had enough crap at home. However, if you care for 2Gb PC2-5300-555 laptop ram, you can come and get it. I'll keep the ABGN Intel wifi card which I will probably use for my next computer build and the 32Gb SSD & 120 mb hard drive. I have no idea if the screen is re-usable, but in case it is - I've got a thin 11" 1366*768 high brightness, led backlit screen here for who's interested ;-)

I will trow both the screen and the memory away by the beginning of next week so if you can use it, let me know quickly so I can keep it around.

Looking for a greener distribution?

Join the thundring herd of geekos!

Last week we released openSUSE 12.3 and the responses from the community and the press were better than ever before. Lots of journalists announced we've moved firmly in the top spot or top-three of favorite distro's and quite a few are running openSUSE now. Seeing the many blog posts, tweets, facebook posts and Google+ discussions, the community feels very much the same!

Now maybe you're not 100% happy with your current distribution. Maybe it isn't entirely stable or you sometimes would like it if things just worked. Or you worry about the decision making process and the future of your current choice. Maybe you don't want to wait for stuff to compile anymore.

I know, the technical differences between distributions are not huge. I'd even argue they are small - differences in philosophy and how they are developed are bigger, however. And I can imagine one feels more comfortable with a project which picks collaboration and sharing over secrecy and Not Invented Here. I know what I prefer. Technically, openSUSE belongs to the top distributions as well. And while nothing is perfect we at least make it darn easy to fix stuff without administrative sillyness.

So whatever the reason for looking somewhere else - I think it is fair to say that openSUSE should be on your short list of distributions to try.

To help with the trying, I called in help from our community and created an openSUSE introduction and a cheat sheet for moving over to openSUSE from a variety of other distributions. Check it out on news.opensuse.org!

As bonus, I'll just give you three links that'll be helpful getting your openSUSE up and running quickly:

• Androbit offers some proprietary applications and drivers
• opensuse-community.org has a one-click-install for patented multimedia stuff
• the software.opensuse.org packages overview is the easiest way to find and install extra or updated software on openSUSE.
• Get some more software installation tips and read some interesting KDE and GNOME tips & tricks.
  

And of course you can download openSUSE 12.3 on software.opensuse.org and find out what is new in the announcement.

Have a lot of fun!