Wednesday, May 6, 2015

Packt Publishing offering about DRM-free content

Packt running a campaign to support 'Day Against DRM':

We believe that you should be able to read and interact with your content when you want, where you want, and how you want – and to that end we've been advocates of DRM-free content since our very first eBook was published back in 2004.

Packt Publishing is offering all its DRM-free content like ebooks & videos at $10 for 24 hours only on May 6th. Please find the link here : bit.ly/1clU3YZ
 
 Packt celebrates International Day Against DRM, May 6th 2015

Packt Publishing firmly believes that you should be able to read and interact with

your content when you want, where you want, and how you want – to that end they

have been advocates of DRM-free content since their very first eBook was published

back in 2004.

This year, to demonstrate their continuing support for Day Against DRM, Packt is

offering all its DRM-free content at $10 for 24 hours only on May 6th – with more than

3000 eBooks and 100 Videos available across the publisher’s website

www.packtpub.com, there’s plenty to discover, whatever you’re interested in.

“Our top priority at Packt has always been to meet the evolving needs of developers

in the most practical way possible, while at the same time protecting the hard work of

our authors. DRM-free content continues to be instrumental in making that happen,

providing the flexibility and freedom that is essential for an efficient and enhanced

learning experience. That’s why we’ve been DRM-free from the beginning – we’ll

never put limits on the innovation of our users.”

– Dave Maclean, CEO

Advocates of Day Against DRM are invited to spread the word and celebrate on May

6th by exploring the full range of DRM-free content at www.packtpub.com - all eBooks

and Videos will be $10 for 24 hours, including the latest hot titles.

Thursday, February 19, 2015

Wonderful opportunity to grab some free and nice books


Press Release
Packt Publishing Encourages Customers to Learn New Skills with 18 Days of Free Learning
Packt Publishing is encouraging customers to develop new skills and try new technologies with 18 days of Free Learning. Beginning on Monday 16th February, the publisher is inviting customers to claim a free eBook every day to learn a new skill and to get to know the wide range of technologies and subjects that can be found across their extensive library of titles.
Each eBook will only be available for free for 24 hours – so make sure you visit Packt’s website every day from the 16th February to March 5th to grab your daily Free Learning fix. With such a wide range of topics tipped to potentially feature – from Drupal to Learning Play, Magento to Moodle, Selenium to OpenLayers, Maya Programming to Linux Shell Scripting, Redmine to BackTrack - be sure to take this opportunity to try something new.
All customers have to do is simply click on the day’s free eBook and it will instantly be added to their account. New customers are also encouraged to take advantage, with the offer being a great opportunity to get to know Packt a little better – all that’s required is a Packt account.
Find out more: <bit.ly/1ECubjf >
#freelearning

Sunday, January 18, 2015

CMetronome

Geek and nerd musicians do not need GUI, do they? You can obtain the release from here. It is already available in AUR for Archlinux. It requires the pulseaudio sound server. It does not depend on any of Qt, just C++. Do not forget about voting in AUR if you like the software. ;-)

Friday, October 4, 2013

Release: cutepaste

You can obtain the release from here. It is already available in AUR for Archlinux (do not forget to vote if you like ;).

Cutepaste in action

Thanks go to Sayak for providing this service!


KDE Paste web client

Wednesday, July 24, 2013

Yocto: mature or not?

This is a bit of fun spoiling post, but sometimes we need to become constructively critical in order to improve the situation. As you may already know, Yocto has been advertised as the relatively new technology for creating custom distributions for you. Although, people commonly use Poky, Arago, and so forth ready-made distributions on top of Open Embedded.

Yocto Project

Cross-compilation


So, here is the critical issue for embedded developers using the cross-toolchain provided by Code Sourcery why I personally think that Yocto might not be usable for the moment for commercial projects where reliability is a main concern.

In short: it does not work if you would like to build the distribution (for instance stock Poky) for your embedded board, like ARM with the sourcery toolchain.

What makes me worry a bit more, this cross-toolchain environment was working in the first half of 2012 yielding some regression in here. That opens up new concerns about QA, right? It is fundamentally broken and can be reproduced easily as acknowledged in the bug report above, yet the changes got in.

One could suggest to revert back to the very old and unsupported version. Well, it is unsupported first of all, so you cannot reliable base a commercial product on top of it. More importantly, that version has a lot more issues. I have tried to back port fixes to that release from master, but I have not had so much fun. I experienced many merge conflicts and so forth.

Cross compilation

Unsupported Archlinux

It is a bit disappointing that such a common distribution as Arch is not supported. Please do not write me that they do not enough manpower. I fully understand and appreciate that. Yet, it means Archlinux developers are in trouble.

Archlinux


Unsupported releases

They, kinda, support two releases back. They have a time based release cycle. One new release comes in every half a year. This brings us to the point that they only support your selected software version up to maximum one year. That is not so comfortable when you need a reliable product. I just faced the issue yesterday that there are fixes in old release branches, but no one has cared to release them for more than half a year. They will probably not be released either. I am now referring to the denzil version coming from April in 2012. So, it is not quite like the Linux kernel or Ubuntu LTS.

Long Term Support (LTS)

Error reporting

I think this is also a hard sell in Yocto as of now. There are issues that I could not simply figure out on my own as a newcomer without quite a bit of time with analyzing, especially when the public documentation is not up to the task either. There are several issues which made me spend a few days just to understand them, and that what is going on underneath.

The first bogus error reporting is about bblayers.conf file mismatch based on the generated file and the sample available. It was even hard for others to provide some help on IRC who have been experienced with the project. Here you can read the details about it.

Then, there is the issue of mismatching cross-compilation toolchain and MACHINE configuration. In my case, I would like to use the arm gnueabi toolchain from gcc for my omap board, particularly for the arm core. All fine, the external sourcery toolchain is setup, but the default config file generated for the build comes with "qemux86". When you try to generate the distribution, you will get weird toolchain issues about x86. I have been surprised because I explicitly specified the toolchain what to build with. Having spent 1-2 days with trying to understand the situation, it boils down to that the default MACHINE config generated, screwed this up. It would have been so much easier if it is reported up front with a warning that the toolchain and machine configurations are mismatching. Here you can find the bugreport about that one.

There are more to it, albeit the last, but not least I would like to mention here is the one when you get tab/space issues when migrating from an older poky version, or you just get those for some reason. Reporting those issues should be easy, shouldn't it? Theoretically yes, but in practice, all you will get a file having issues tab and space issues. I did not quite get the point what the issue is after checking the offending file for quite a while. It turned out that the real problem is in the include file which it was requiring. Again, a newbie would spend a lot of time with it without external and professional support. I would even go further than reporting the right file as in: it would be nice to get a report for the location as close as possible. That is, a function name, perhaps a list of offending line numbers, and so forth. Here you can find the relevant bugreport for this.

Please note that, I have been told for some of these that it is not an easy fix as the parser design is not prepared for such use cases. It unfortunately means, it is not just about adding a minor feature, but basically revamping the parser.

Error messages

Documentation

There are some issues here as well I hit. I had a DISTRO_FEATURE entry "--disable-zlib" that I inherited. I was looking into it, but I have not seen anything like that in the reference manual. I guessed respestively that, it is not a proper syntax, so I can remove it. Right, you would imagine it could be as simply as that?

The problem is that, yes, theoretically, but in practice: I have seen other undocumented DISTRO_FEATURES like "opengl". I opened up a bugreport for that, but the problem is that, once you find a feature not documented, how will you know what to do with another not represented. Is that a mistake, undocumented, or what exactly? :)

I would not like to bore the reader, so I will only give one more example in here. I have been told that external toolchains should work, yet, it is not documented in the released documentation properly. Even in the development version of the next generation documentation, it is a bit of sloppy. You get the documentation of 2-3 variables, but you do not have any concrete example at hand. Then, I have been told to use the meta-toolchain/sourcery layer. As for the latter, I do not even find any documentation that could be useful for me on github from Mentor Graphics. I created a bugreport for that one, too.

Dr. Documentation

Conclusion

I am objectively pessimistic with the current state as an Arch user who is looking for a reliable product in an embedded environment with cross-compilation. I have spent a couple of days to experiment with all this, and I just wanted to let you the limitations so that you do not need to go through the same issues. Oh, and please do not write that "It works for me" because yes, I heard people using git master or not even that with supported distributions, and very simple setups where cross-toolchain is not necessary, et cetera. I am now referring to Arch, embedded, and so forth scenarios. I of course appreciate the Yocto people's work a lot, and I hope they can put more effort into this project to address those issues in the, hopefully near, future.

Conclusion

Saturday, July 20, 2013

aKademy mola (i.e. rocks)

Back in the UK!

While having a short discussion with David Edmundson at the Stansted airport in London, we realized that this has been one of the best annual KDE summits we attended to. We made a note that the organization team always kept us busy with awesome social programs.


One of those funny pictures

I think Milian summarizes it in his blog post well: "The reason why I didn’t write a single blog post in between is just that I never had a spare minute for that. "

Many thanks go to the sponsors, organizers and participants who made this vacation in Spain an unforgettable success. ;-)

Photos, blog posts and other information can be found on the official web page.