Interesting Links – June 2013

Not a lot of links this month – people must be getting progressively more boring! Or it could be I went on holiday for a week with NO INTERNET. Now you have recovered from that horror, time for some links:

  • Ubuntu is making progress with Mir
  • But Mir will not be used by either Kubuntu or Lubuntu
  • Speaking of X replacements, some more info about Wayland
  • The LAS did a one week Arch Challenge, as did someone else.
  • Reports vary about what the default browser will be in the next Ubuntu. Possibly Chromium?
  • Some cgroups changes will be happening in systemd
  • And some more answers to systemd concerns
  • LLVM 3.3 has full C++11 support, in contrast to gcc-4.8.1 that sort of did…
  • Some interesting decisions in the RHEL7 roadmap
  • A useful table detailing toolchain component compatibility for building cross compilers
  • And should I be concerned my Nexus 7 will slow down?

Leaving Identi.ca

When I saw the message that Identi.ca was switching to the pumpio platform, I started thinking when the last time I actually used it was. Turns out, it was the end of 2012. At that time I also discovered post formats for WordPress and saw the status post seems to be a replacement for tweeting.

So I have decided that all my short posts can happen here. This was a driving force to find a new theme, because my old one did not support status posts. Import my old tweets (or whatever they were called on identi.ca) and I am up and running!

The reason I am posting this here is that if people are following my main RSS, they will get the occasional “tweet” from me. If you want to avoid that, the “tweet” category can be excluded using this link.

C++11 – Part 8: Rvalue References and Move Semantics

While moving my hosting I noticed some posts that I never bothered tidying up to post. And although there has been a bit of a break, I am still writing these introduction to C++11 posts. Chances are low that I will have the C++11 posts finished before C++14 arrives! Moving on…

Consider the following code snippet:

template swap(T& a, T& b) {
  T t(a);   // #1
  a = b;    // #2
  b = t;    // #3
}

On line #1, we end up with two copies of a, line #2 gives two copies of b and line three is back to two copies of (the original) a. If T is a type that requires extensive copying this requires quite a bit of overhead. The standard library has specialized cases for std::vector and std::string to remove that overhead, but it would be good to get rid of it in general.

Lets consider another example:

T foo() {
  T t;
  // do "foo" on t...
  return t;
}
T u = foo();

Here foo() returns a temporary copy of t constructed on the stack and then that is passed to the T copy constructor to initialize u. Again this can have a substantial overhead. (I am ignoring return-type optimization here…)

From these examples, it should be clear that such overhead is reasonably common in C++ (and seems to be one of the biggest criticisms of the language). To fix this, a new non-const reference type is added in C++11, called an r-value reference and denoted T&&.

Firstly, what is an r-value? They are temporary objects that tend to fall on the right hand side of an equation. Because they are temporary objects, you can not assign to them. Also, you can not assign a r-value to a regular reference. E.g.

int& foo = bar()

will fail because bar() is returning a temporary value, which would be bad if it was able to be modified.

Using the r-value reference, we can add what is termed a “move constructor” and a “move assignment operator” to our class:

Foo::Foo(Foo&& f);
Foo& Foo::operator=(Foo&& f);

Note their arguments are both non-const, the reasons for which should become obvious.

Lets look at the copy constructor some more. For the sake of this example I will assume that Foo only contains an array and a variable storing its size. The copy constructor would look something like:

Foo::Foo(Foo&& f) {
  size=f.size;
  array=f.array;
  f.size=0;
  f.array=NULL;
}

What the move constructor has done is pilfered the resources of the temporary object, then reset the temporary object’s resources to being empty. This saves overhead of copying the array and setting the NULL prevents the memory being freed when the temporary object goes out of scope. The move assignment operator is exactly the same, except it frees any resources it currently owns first (like a normal assignment operator does).

How does this help our situation in the swap function above? We tell the compiler that it is OK to treat the right hand side of all the assignments as r-values using the std::move() function. So, the function becomes:

template swap(T& a, T& b) {
  T t(move(a));
  a = move(b);
  b = move(t);
}

Now at any time there is only one copy of a and b and the copying does not require any storage overhead.

Posted in C++11 on by Allan Comments Off on C++11 – Part 8: Rvalue References and Move Semantics

Shout-Out To Me on LAS (Not Really…)

For those that have not seen it, this week the Linux Action Show did a a wrap-up of their week long Arch challenge. If you are interested in that bit, start here… With praise such as “it is really not that bad”, I guess Arch Linux is doing well!

I got two indirect shout-outs. Clearly I am the developer who has an “ounce of contempt“. I live in the metric world, so that is 28.3495g, which seems relatively little. I also get a shout-out in their IRC screen! And to be clear, I am not a “my way is always right type”, it just works out that way.

Interesting Links – May 2013

Guess what? May has finished… Well, it surprised me at least!

Linux distribution and software related links:

  • All binaries in Arch will move to /usr/bin in the next couple of days.
  • CinnArch turned into Antergos
  • But why do that when there is Debian?
  • And this tells you why you should not develop software for a single distribution.
  • Surprise! Do not believe what you see on Phoronix.
  • Hi LWN. When you say I posted in April, you should note it was last year
  • People still ranting against systemd. I hear there are alternatives
  • The 3.10 Linux kernel will tick less
  • Wayland has progressed enough to be on a live CD
  • GCC-4.8.1 has implemented all the major features of C++11 – which reminds me that I still have posts waiting in my C++11 series…
  • Some changes in the world of package management for Fedora
  • On the topic of package management, read about subslots in Gentoo
  • Interesting security issues in both the Linux kernel and Xorg this month.

And some other stuff…

  • identi.ca is moving to pumpio. I’ll probably remove my account there soon anyway…
  • Here is a time-lapse of this xkcd epic.

Ways To Contribute To Arch Linux

I have been asked quite often recently “what is some ways I can contribute to Arch Linux?”. And the usual answers apply – package for the AUR, contribute to the wiki, help out on the forums and IRC… All useful to the whole community, but being not selfless at all I really want people to help in a way that helps me! So here are some ideas:

#1 – Fix Bugs on the Bug Tracker

This is not a new suggestion either… but it is an area that I think most people could contribute. I would say that there is some things that can be done to reduce the work for the developer that they are assigned to for the majority of bug reports in our tracker. For example:

  • Check that you can (still) replicate the bug. If you can, do not post “ME TOO!” as a comment. Just add a vote. Unless of course you can provide more information.
  • Summarize links to external reports. I hate bugs that are reported with just a link to a forum post or another bug tracker that requires me to read pages of posts to get at the issue. A brief summary of how to replicate is very useful.
  • For upstream bugs, make sure they are reported upstream. Provide the link to the upstream bug report or mailing list, etc.
  • If upstream has a patch for the issue, test it. If it works, provide the updated PKGBUILD and patch in the bug tracker, making sure a there is a comment in the PKGBUILD about where the patch came from.

#2 – Ensuring Continuously Buildable Arch

Arch rolls along a breakneck speed and quite often a package that was built a few weeks ago will no longer build from ABS. Then we get bug reports in the form “foo does not build”. In fact, most of those bug reports do not even provide build error (stupid users…)! These bugs particularly annoy me because I really dislike ABS in its current form. However, having packages that always build is very helpful when we do rebuilds due to library soname bumps or some change in packaging policy.

What I would propose is forming a group of people who in some way are continuously rebuilding Arch packages. That should be easy to script with the use of our devtools scripts. Any time a package no longer builds, the issue is investigated, reported upstream (if needed) and a fixed PKGBUILD is posted on the bug tracker. That way the developer only needs to quickly scan the updated PKGBUILD, confirm the fix is good, and push the rebuild to the repos.

#3 – Forming an Arch Security Team

Currently, Arch has a rather ad-hoc approach of dealing with security issues. This is because the majority of security fixes result in a new version of software being released, so we get them quickly with an update anyway. Also, developers tend to follow the mailing lists of the software they maintain. However, Arch could benefit from team who keep track of new security issues and make sure our packages get fixed. It would be worth doing a review of the current package situation too…

There was a project called “Arch Sheriff” a while ago that attempted to do this. However, I think it failed for two main reasons. It required the developers to go to an external website to check if their packages were vulnerable and, to a much lesser extent, it required them to go find the upstream fixes. A much better approach would be for the security team to interact with the developers through the bug tracker, providing fixed PKGBUILDs that include links to the issue and the upstream fix as comments.

#4 – Buy Allan Beer

On second thoughts, that probably hinders rather than helps…

For ideas #2 and #3, there will be some groundwork needed to get this underway. I guess using IRC, the wiki and mailing-lists should be enough for organizing how they will be run. I would not be directly involved in any of those ideas (they are suppose to free up my time!) but can advise and provide a middle man to the developers if needed. Continuously building packages for idea #2 would also require computing resources, but I guess that could be spread across people in the group.

So what are you waiting for? Get doing stuff!

Hello DigitalOcean!

While my old hosting with Laughing Squid was did its job, I was very limited in what I could do with it. Access only via sftp, 1GB of storage and I was breaking my monthly 25GB traffic limit fairly frequently… So it was time to look for something new.

For me, the primary consideration when choosing a provider is price. My website is not really worth any investment… A thread on reddit pointed me at DigitalOcean (which may or may not be spelled with a space…). It was cheap at $5 per month – in fact cheaper than what I was paying – and 20GB storage on SSD with 1TB transfer is more than enough for me. I also figure that one core and 512MB RAM is enough for my requirements. As a bonus, they provide Arch Linux images, which I am mildly familiar with administrating.

Time to create a “droplet” as they are called. I chose the 32bit Arch install given the low RAM available to me and selected the San Francisco data center given where I live. The DigitalOcean front page tells me this will take 55 seconds. It took 69 seconds but I think I will forgive that! I get an IP address and can ssh in. All good so far.

Checking out what packages are installed, it appears to be all of the base and base-devel groups and ssh. The base-devel group probably is not needed, so I start by removing a whole bunch of those packages including autotools, binutils and gcc. Also, the system is installed on a single ext4 partition, so I can get rid of all packages to deal with other file system types. There are probably other unnecessary packages installed too, but the install really does not take up that much space. And it is not as if Arch is designed to be super slim anyway.

Time to update. The image is from 2013.03, so should be straight forward. Hrmm…

warning: linux: ignoring package upgrade (3.8.4-1 => 3.9.3-1)
warning: linux-api-headers: ignoring package upgrade (3.7.3-1 => 3.8.4-1)

Lets peak in pacman.conf:

###############################################################################
# Please note: if you update the linux kernel via pacman and reboot, you will
# lose access to your droplet! Please don't remove 'linux linux-api-headers'
# from IgnorePkg.
###############################################################################
IgnorePkg = linux linux-api-headers

Well, that is not right, but quite a common mistake. The package linux-api-headers provides userspace headers for the toolchain, so its update is linked to updates in glibc, gcc etc and not that of the kernel. The linux-headers package provides kernel headers, but is not needed on a VPS. So I open a support ticket suggesting this is fixed. This is where I was impressed. I got an initial acknowledgment response within minutes (from what is potentially an actual person) and further responses before the end of the day from people high up the food chain.

Looking further into the install, it is using netcfg to connect to the network. I guess this will need to be upgraded to netctl one day, but given I have never used either of those, I think I will save that for later. The netcfg configuration file that appears to be automatically set-up during droplet creation looks a bit of a mess, but works.

That is all I could see that is changed from a vanilla Arch install, so overall everything is exactly as I would expect.

I suppose the only other thing to look at is the Digital Ocean control panel. It provides everything I would expect – console access, power cycling, backup facilities. Not sure about having a “root password reset” function though… From there you can update your kernel to a recent Arch one (3.9.2-1). This is something I don’t quite understand. It is the Arch packaged kernel (as demonstrated by the pacman -Qi output), so something is happening in the background on update that is not happening when doing it via the package manager. I wonder if they could do whatever that is via our packaging system and provide a repository allowing a direct update of the kernel.

I can not really conclude much from a couple of days testing, but all seems good and speeds are fine… I think I have my website completely transfered (with only a small redirection “https” + “www prefix” combination issue to fix), so let me know if anything is out of order.

Death of the [allanbrokeit] repository

I have deleted the [allanbroke] repository. It was started mainly to test the PGP signing implementation in pacman, which is now well established. Also, I would delay any packaging of release candidates or beta releases for this repository until I had enough free time and often official releases were made before that happened.

The repository may return someday, perhaps with VCS builds of packages I use locally once I get around to automating their creation as that would require no extra work…

Interesting Links – April 2013

What’s that? It is now May and it has been for a few days… Better do this post then!

News from the world of distributions:

  • This relatively unknown distro got a release…. (Raring Ringtail)
  • Although there might be a lack of co-operation between them and Debian
  • Fedora 19 was slightly delayed.
  • openSUSE is doing lots of ARM stuff.
  • Debian Wheezy should be released soon
  • Sabayon is rolling out systemd.
  • What is the best distro? If you can access Linux Format, you will see… (Arch was runner up in the power-distro section.
  • And here is how to choose a distro that suites you… I got Arch even without demanding pacman, but Qubes OS and Slakel were close runners up. Never heard of them!
  • DragonFly BSD 3.4 was released using GCC-4.7.
  • An interesting addition of the /extra hierarchy by Chakra.

Software releases and news of interest:

  • A remote desktop backend was merged into Wayland
  • Speaking of Wayland, it got updated.
  • Google forks Webkit in a Blink (was my pun better than the articles?)
  • R-3.0.0 was released. Grab it from the Arch [testing] repo.
  • Chakra released Alpha 2 of the Akabei package manager
  • A project to set-up a lightweight KDE desktop.
  • GDB 7.6 added AArch64 support.
  • The Open Build Service 2.4 was released with supports PKGBUILDs… although I’m sure I posted it did before in one of these.
  • A talk about Glibc development.
  • Another attempt as SELinux on Arch
  • Clang is C++11 complete when 3.3 gets released.

And some fun stuff to finish:

  • The value of case badges. My laptop has an Apple logo, so that must really boost speed given the price it adds.
  • A simple game of 22 vs 11.
  • The revenge of the game developer.

We Are Not That Malicious…

I will clarify this just because I have had several people ask me already. No, we did not remove the SyncFirst option in pacman to deliberately cause issues for Manjaro Linux. In fact, it was first discussed in Feburary 2012 and, as far as I can tell, Manjaro has only been around from late March 2012 (looking at the earliest commits in their git repository).

So lets keep the conspiracy theories to a minimum! (or at least come up with a better one…)