Feed aggregator

Ubuntu Insights: Ubuntu Core – how to enable aliases for your snaps commands

Planet Ubuntu - Sat, 01/28/2017 - 04:00

We are happy to announce that a new version of Ubuntu Core, based on snapd 2.21, has been released to the stable snaps channel yesterday.

As with any stable release, your Ubuntu Core devices will update and reboot automatically. If you are using snaps on the desktop, the release will reach you through a snapd package update on Ubuntu 16.04, 16.10 and 17.04.

This release comes with several improvements you can read about in the changelog, but let’s focus on a big feature that will help people who snap very large software, especially software that comes with many commands (such as OpenStack, ImageMagick, most databases…) and their users.

Introducing snap aliases

When you launch a snap from the command line, you need to use the name of the snap, then the name of a command it contains. In most cases, you don’t notice it, because snapd simplifies the process by collapsing <snap-name>.<command-name> into <command-name>, when both are the same. This way, you don’t need to type inkscape.inkscape, but simply inkscape and get a familiar software experience.

But when a snap contains multiple commands, with various names, things can become less familiar. If we take the PostgreSQL snap as an example, we can see it comes with many commands: initdb, createdb, etc. In this case, you have to run postgresql96.initdb, postgresql96.createdb, etc.

The alias feature of snapd lets snaps declare their own aliases, for users to manually enable after install or for snap stores to declare as “auto-aliases” that will be enabled upon install.

How to enable aliases

To have an overview of all available aliases on a system, you can use the snap aliases command.

$ snap aliases App Alias Notes firefox-devel.firefox firefox -

You can see I have a snap with the name firefox-devel, containing a firefox command and a firefox alias.

I can either use firefox-devel.firefox as my command to launch Firefox, or use snap alias <snap-name> <alias> to enable the alias.

$ snap alias firefox-devel firefox $ snap aliases App Alias Notes firefox-devel.firefox firefox enabled

I can now launch my firefox-devel snap with the firefox command.

You can also use snap unalias to disable aliases for a specific snap.

How to declare an alias

Declaring a new alias in your snap is as easy as adding one more entry to your snapcraft.yaml apps keys.

$ cat firefox-devel/snapcraft.yaml [...] apps: firefox-devel: command: bin/firefox aliases: [firefox] [...]

That’s it, heads-on to tutorials.ubuntu.com to make your own snap from scratch and give aliases a try!

Nathan Haines: We're looking for Ubuntu 17.04 wallpapers right now!

Planet Ubuntu - Sat, 01/28/2017 - 01:08
We're looking for Ubuntu 17.04 wallpapers right now!

Ubuntu is a testament to the power of sharing, and we use the default selection of desktop wallpapers in each release as a way to celebrate the larger Free Culture movement. Talented artists across the globe create media and release it under licenses that don't simply allow, but cheerfully encourage sharing and adaptation. This cycle's Free Culture Showcase for Ubuntu 17.04 is now underway!

We're halfway to the next LTS, and we're looking for beautiful wallpaper images that will literally set the backdrop for new users as they use Ubuntu 17.04 every day. Whether on the desktop, phone, or tablet, your photo or can be the first thing Ubuntu users see whenever they are greeted by the ubiquitous Ubuntu welcome screen or access their desktop.

Submissions will be handled via Flickr at the Ubuntu 17.04 Free Culture Showcase - Wallpapers group, and the submission window begins now and ends on March 5th.

More information about the Free Culture Showcase is available on the Ubuntu wiki at https://wiki.ubuntu.com/UbuntuFreeCultureShowcase.

I'm looking forward to seeing the 10 photos and 2 illustrations that will ship on all graphical Ubuntu 17.04-based systems and devices on April 13th!

The Fridge: Zesty Zapus Alpha 2 Released

Planet Ubuntu - Fri, 01/27/2017 - 20:23

“Without deviation from the norm, progress is not possible.”

― Frank Zapus

The second alpha of the Zesty Zapus (to become 17.04) has now been released!

This milestone features images for Lubuntu, Kubuntu, Ubuntu MATE, Ubuntu Kylin, Ubuntu GNOME, and Ubuntu Budgie.

Pre-releases of the Zesty Zapus are not encouraged for anyone needing a stable system or anyone who is not comfortable running into occasional, even frequent breakage. They are, however, recommended for Ubuntu flavor developers and those who want to help in testing, reporting and fixing bugs as we work towards getting this release ready.

Alpha 2 includes a number of software updates that are ready for wider testing. This is still an early set of images, so you should expect some bugs.

While these Alpha 2 images have been tested and work, except as noted in the release notes, Ubuntu developers are continuing to improve the Zesty Zapus. In particular, once newer daily images are available, system installation bugs identified in the Alpha 2 installer should be verified against the current daily image before being reported in Launchpad. Using an obsolete image to re-report bugs that have already been fixed wastes your time and the time of developers who are busy trying to make 17.04 the best Ubuntu release yet. Always ensure your system is up to date before reporting bugs.

Lubuntu

Lubuntu is a flavor of Ubuntu based on LXDE and focused on providing a very lightweight distribution.

The Lubuntu 17.04 Alpha 2 images can be downloaded from:

More information about Lubuntu 17.04 Alpha 2 can be found here:

Ubuntu MATE

Ubuntu MATE is a flavor of Ubuntu featuring the MATE desktop environment for people who just want to get stuff done.

The Ubuntu MATE 17.04 Alpha 2 images can be downloaded from:

More information about Ubuntu MATE 17.04 Alpha 2 can be found here:

Ubuntu Kylin

Ubuntu Kylin is a flavor of Ubuntu that is more suitable for Chinese users.

The Ubuntu Kylin 17.04 Alpha 2 images can be downloaded from:

More information about Ubuntu Kylin 17.04 Alpha 2 can be found here:

Kubuntu

Kubuntu is the KDE based flavor of Ubuntu. It uses the Plasma desktop and includes a wide selection of tools from the KDE project.

The Kubuntu 17.04 Alpha 2 images can be downloaded from:

More information about Kubuntu 17.04 Alpha 2 can be found here:

Ubuntu GNOME

Ubuntu GNOME is a flavor of Ubuntu featuring the GNOME desktop environment.

The Ubuntu GNOME 17.04 Alpha 2 images can be downloaded from:

More information about Ubuntu GNOME 17.04 Alpha 2 can be found here:

Ubuntu Budgie

Ubuntu Budgie is a flavor of Ubuntu featuring the Budgie desktop environment.

The Ubuntu Budgie 17.04 Alpha 2 images can be downloaded from:

More information about Ubuntu Budgie 17.04 Alpha 2 can be found here:

If you’re interested in following the changes as we further develop the Zesty Zapus, we suggest that you subscribe to the ubuntu-devel-announce list. This is a low-traffic list (a few posts a month or less) carrying announcements of approved specifications, policy changes, alpha releases, and other interesting events.

A big thank you to the developers and testers for their efforts to pull together this Alpha release, and welcome Ubuntu Budgie!

Originally posted to the ubuntu-devel-announce mailing list on Fri Jan 27 21:16:28 UTC 2017 by Simon Quigley on behalf of the Ubuntu Release Team

Zesty Zapus Alpha 2 Released

The Fridge - Fri, 01/27/2017 - 20:10

“Without deviation from the norm, progress is not possible.”

― Frank Zapus

The second alpha of the Zesty Zapus (to become 17.04) has now been released!

This milestone features images for Lubuntu, Kubuntu, Ubuntu MATE, Ubuntu Kylin, Ubuntu GNOME, and Ubuntu Budgie.

Pre-releases of the Zesty Zapus are not encouraged for anyone needing a stable system or anyone who is not comfortable running into occasional, even frequent breakage. They are, however, recommended for Ubuntu flavor developers and those who want to help in testing, reporting and fixing bugs as we work towards getting this release ready.

Alpha 2 includes a number of software updates that are ready for wider testing. This is still an early set of images, so you should expect some bugs.

While these Alpha 2 images have been tested and work, except as noted in the release notes, Ubuntu developers are continuing to improve the Zesty Zapus. In particular, once newer daily images are available, system installation bugs identified in the Alpha 2 installer should be verified against the current daily image before being reported in Launchpad. Using an obsolete image to re-report bugs that have already been fixed wastes your time and the time of developers who are busy trying to make 17.04 the best Ubuntu release yet. Always ensure your system is up to date before reporting bugs.

Lubuntu

Lubuntu is a flavor of Ubuntu based on LXDE and focused on providing a very lightweight distribution.

The Lubuntu 17.04 Alpha 2 images can be downloaded from:

More information about Lubuntu 17.04 Alpha 2 can be found here:

Ubuntu MATE

Ubuntu MATE is a flavor of Ubuntu featuring the MATE desktop environment for people who just want to get stuff done.

The Ubuntu MATE 17.04 Alpha 2 images can be downloaded from:

More information about Ubuntu MATE 17.04 Alpha 2 can be found here:

Ubuntu Kylin

Ubuntu Kylin is a flavor of Ubuntu that is more suitable for Chinese users.

The Ubuntu Kylin 17.04 Alpha 2 images can be downloaded from:

More information about Ubuntu Kylin 17.04 Alpha 2 can be found here:

Kubuntu

Kubuntu is the KDE based flavor of Ubuntu. It uses the Plasma desktop and includes a wide selection of tools from the KDE project.

The Kubuntu 17.04 Alpha 2 images can be downloaded from:

More information about Kubuntu 17.04 Alpha 2 can be found here:

Ubuntu GNOME

Ubuntu GNOME is a flavor of Ubuntu featuring the GNOME desktop environment.

The Ubuntu GNOME 17.04 Alpha 2 images can be downloaded from:

More information about Ubuntu GNOME 17.04 Alpha 2 can be found here:

Ubuntu Budgie

Ubuntu Budgie is a flavor of Ubuntu featuring the Budgie desktop environment.

The Ubuntu Budgie 17.04 Alpha 2 images can be downloaded from:

More information about Ubuntu Budgie 17.04 Alpha 2 can be found here:

If you’re interested in following the changes as we further develop the Zesty Zapus, we suggest that you subscribe to the ubuntu-devel-announce list. This is a low-traffic list (a few posts a month or less) carrying announcements of approved specifications, policy changes, alpha releases, and other interesting events.

A big thank you to the developers and testers for their efforts to pull together this Alpha release, and welcome Ubuntu Budgie!

Originally posted to the ubuntu-devel-announce mailing list on Fri Jan 27 21:16:28 UTC 2017 by Simon Quigley on behalf of the Ubuntu Release Team

Ubuntu Insights: Award-winning drone technology with Ubuntu

Planet Ubuntu - Fri, 01/27/2017 - 10:28

The market for drones is exploding as businesses and individuals embrace them. The global market for commercial applications of drone technology will balloon to as much as $127 billion by 2020 up from £2billion today (PWC.) Aerotenna is one of those innovators making this vision a reality.

Aerotenna’s award-winning technology seeks to solve the UAV autonomous flight-challenges – preventing UAVs from colliding with non-cooperative objects or other UAVs. Check out this video that shows it in action:

Autonomous Collision Avoidance- Mission from Aerotenna on Vimeo.

To learn more about Aerotenna’s award-winning technology download the case-study below. Highlights include:

  • Partnering with Intel® and Xilinx®, Aerotenna developed and released OcPoC with Altera Cyclone and Xilinx Zynq, with an industry-leading 100+ I/Os for sensor integration, and FPGA for sensor fusion, real-time data processing and deep learning
  • One such sensor is Aerotenna’s microwave radar that allows the drone to detect surrounding objects in all light conditions and environments, important for safe flying of UAVs
  • Ubuntu powers the OcPoC giving developers a familiar, extensible platform to build drone solutions based on the powerful combination of multiple sensors and complex robotics algorithms

Download the case study

Ubuntu Insights: ROS on arm64 with Ubuntu Core

Planet Ubuntu - Fri, 01/27/2017 - 10:03

This is a guest post by Kyle Fazzari, Engineer from Canonical. If you would like to contribute a guest post, please contact ubuntu-devices@canonical.com

Previous Robot Operating System (ROS) releases only supported i386, amd64, and armhf. I even tried building ROS Indigo from source for arm64 about a year ago, but ran into dependency issues with a missing sbcl. Well, with surprisingly little fanfare, ROS Kinetic was released with support for arm64 in their prebuilt archive! I thought it might be time to take it for a spin with Ubuntu Core and its arm64 reference board, the DragonBoard 410c, and thought I’d take you along for the ride.

Step 1: Install Ubuntu Core

The first order of business is to install Ubuntu Core on the DragonBoard. Just follow the documentation. I want to mention two things for this step, though:

  1. I’ve never had good luck with wifi on the DragonBoard, it seems incredibly unstable. I recommend not even bothering with it and using a USB to ethernet adapter, since with Ubuntu Core at least your first login must be over SSH.
  2. There’s a bug that causes the first boot wizard to take quite some time between entering your SSO password and finishing. Don’t worry, just leave it alone, it’ll finish (mine took about 7 minutes).
Step 2: Make sure it’s up-to-date

SSH into the machine (or if you set a password, login locally, it doesn’t matter), and run the following command to ensure everything is completely up-to-date:

$ sudo snap refresh

If it updated, you may need to reboot. Go ahead and do that now, we’ll wait.

Step 3: Install Snapcraft

You may or may not be familiar with Ubuntu Core, but the first thing people typically notice is that is doesn’t use Debian packages (.debs), it uses snaps (read up on them, they’re pretty awesome). However, in this case, they don’t give us what we need, which is a development environment. We need to build a ROS workspace into a snap, which means we’ll need to utilize ROS’s archive as well as the snap packaging tool, snapcraft. All of these are available as .debs. Fortunately, the environment we want is available as a snap:

$ snap install classic --edge --devmode $ sudo classic <unpacking stuff... snip> (classic)kyrofa@localhost:~$

The (classic) prompt modifier tells you that you’re now in a classic shell. Now you can do familiar things such as update the package index and install Snapcraft, both of which you should do now:

(classic)kyrofa@localhost:~$ sudo apt update (classic)kyrofa@localhost:~$ sudo apt install snapcraft Step 4: Workaround bug #1650207

Take a look at your Linux workstation (not the DragonBoard). For example, I’m running Ubuntu Xenial. The contents of my /etc/lsb-release file look like this:

DISTRIB_ID=Ubuntu DISTRIB_RELEASE=16.04 DISTRIB_CODENAME=xenial DISTRIB_DESCRIPTION="Ubuntu 16.04.1 LTS"

Multiple utilities, include Snapcraft and Catkin (the build system for ROS) use this file to determine the OS upon which it’s running. This file looks a bit different on Ubuntu Core:

DISTRIB_ID="Ubuntu Core" DISTRIB_RELEASE=16 DISTRIB_DESCRIPTION="Ubuntu Core 16"

As of this writing, due to a bug, the classic shell doesn’t replace this file with one that looks like Xenial’s, which means that neither Snapcraft nor Catkin (and various other tools) will work correctly. Fortunately that file is writable, so we can work around that just by making Ubuntu Core’s /etc/lsb-release looks like Xenial’s:

(classic)kyrofa@localhost:~$ cat << EOF | sudo tee /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=16.04 DISTRIB_CODENAME=xenial DISTRIB_DESCRIPTION="Ubuntu 16.04.1 LTS" EOF Step 5: Build your snap

Probably the most simple ROS workspace you can imagine is a single talker and a single listener. Snapcraft has exactly that as one of its demos, so for this example we’ll just use that (you might consider reading that demo’s walkthrough). First though, that means fetching the Snapcraft source code:

(classic)kyrofa@localhost:~$ sudo apt install git (classic)kyrofa@localhost:~$ git clone https://github.com/snapcore/snapcraft (classic)kyrofa@localhost:~$ cd snapcraft/demos/ros

The ROS demo in question will by default actually build for Indigo. But you’re interested in arm64! You can’t use Indigo. You need something newer… something shinier, and perhaps less purple. You need to use Kinetic. You tell Snapcraft this by utilizing the rosdistro property. Open up the snapcraft.yaml and edit the appropriate section to look like this (added text bolded):

[...] parts: ros-project: plugin: catkin source: . rosdistro: kinetic catkin-packages: - talker - listener include-roscore: true

Save that file and exit. Finally, it’s time to run snapcraft and watch that workspace get built into a snap (this will take a bit, the DragonBoard is not a blazing workhorse; if you want something faster use the snap builders):

(classic)kyrofa@localhost:~/snapcraft/demos/ros$ snapcraft <snip pulling, building, staging> Priming ros-project Snapping 'ros-example' Snapped ros-example_1.0_arm64.snap

In the end you have a snap. You should exit out of the classic shell at this point (e.g. ctrl+d).

Step 6: Install and run it!

Now it’s time to install the snap you just built. Even though you’ve exited the classic shell, your $HOME remained the same, so you can install the snap like so:

$ cd snapcraft/demos/ros $ sudo snap install --dangerous ros-example_1.0_arm64.snap

(remember the –dangerous flag is because you just built the snap locally, so snapd can’t verify its publisher. You’re telling it that’s okay.)

Finally, run the application contained within the snap (it’ll launch the talker/listener system):

$ ros-example.launch-project <snip> SUMMARY ======== PARAMETERS * /rosdistro: kinetic * /rosversion: 1.12.6 NODES / listener (listener/listener_node) talker (talker/talker_node) auto-starting new master <snip> process[talker-2]: started with pid [25827] process[listener-3]: started with pid [25828] [ INFO] [1485394763.340461416]: Hello world 0 [ INFO] [1485394763.440354547]: Hello world 1 [ INFO] [1485394763.540334917]: Hello world 2 [ INFO] [1485394763.640330599]: Hello world 3 [ INFO] [1485394763.740335917]: Hello world 4 [ INFO] [1485394763.840366912]: Hello world 5 [ INFO] [1485394763.940342594]: Hello world 6 [ INFO] [1485394764.040321141]: Hello world 7 [ INFO] [1485394764.140323334]: Hello world 8 [ INFO] [1485394764.240328548]: Hello world 9 [ INFO] [1485394764.340319074]: Hello world 10 [INFO] [1485394764.341486]: I heard Hello world 10 [ INFO] [1485394764.440333194]: Hello world 11 [INFO] [1485394764.441476]: I heard Hello world 11 [ INFO] [1485394764.540333772]: Hello world 12 [INFO] [1485394764.541450]: I heard Hello world 12 Conclusion

I haven’t yet pushed ROS’s arm64 support very hard, but I’m thoroughly pleased that support is present. Particularly paired with snaps and Ubuntu Core, I think this opens the door to a lot of amazing robotic possibilities.

Original post can be found here.

Rhonda D&#39;Vine: Icona Pop

Planet Ubuntu - Fri, 01/27/2017 - 06:22

Last fall I went to a Silent Disco event. You get wireless headphones, a DJane and a DJ were playing music on different channels, and you enjoy the time with people around who can't hear what you hear. It's a pretty funny experience, and it was one of the last warm sunny days. There I heard a song that was just in the mood for the moment, and made me looking up the band to listen more closely to them.

The band was Icona Pop, they have a mood enlighening pop sound that cheers you up. Here are the songs I want to present you today:

  • I Love It: The first song I heard from them, and I Love It!
  • Girlfriend: Sweet song, and probably part of the reason they are well received in the LGBTIQ community.
  • All Night: A song/video with a message.

Like always, enjoy!

/music | permanent link | Comments: 0 |

Ubuntu Insights: Using the ubuntu-app-platform content interface in app snaps

Planet Ubuntu - Thu, 01/26/2017 - 08:44

This is a guest post by Olivier Tilloy, Engineer at Canonical. If you would like to contribute a guest post, please contact ubuntu-devices@canonical.com

Recently the ubuntu-app-platform snap has been made available in the store for application developers to build their snaps without bundling all their dependencies. The ubuntu-app-platform snap includes standard Qt libraries (version 5.6.1 as of this writing) and QML runtime, the ubuntu UI toolkit and related dependencies, and oxide (a web engine based on the chromium content API and its QML bindings).

This allows app developers to declare a dependency on this snap through the content sharing mechanism, thus reducing dramatically the size of the resulting app snaps.

I went through the exercise with the webbrowser-app snap. This proved surprisingly easy and the size of the snap (amd64 architecture) went down from 136MB to 22MB, a sizeable saving!

For those interested in the details, here are the actual changes in the snapcraft.yaml file: https://bazaar.launchpad.net/~phablet-team/webbrowser-app/staging/revision/1576

Essentially they consist in:

  • Using the ‘platform’ plug (content interface) and specifying its default provider (‘ubuntu-app-platform’)
  • Removing pretty much all stage packages
  • Adding an implicit dependency on the ’desktop-ubuntu-app-platform’ wiki part
  • Adding an empty ‘ubuntu-app-platform’ directory in the snap where snapd will bind-mount the content shared by the ubuntu-app-platform snap

Note that the resulting snap could be made even smaller. There is a known bug in snapcraft where it uses ldd to crawl the dependencies, ignoring the fact that those dependencies are already present in the ubuntu-app-platform snap.

Also note that if your app depends on any Qt module that isn’t bundled with ubuntu-app-platform, you will need to add it to the stage packages of your snap, and this is likely to bring in all the Qt dependencies, thus duplicating them. The easy fix for this situation is to override snapcraft’s default behaviour by specifying which files the part should install, using the “snap” section (see what was done for e.g. address-book-app at https://code.launchpad.net/~renatofilho/address-book-app/ubuntu-app-platform/+merge/311351).

Harald Sitter: KDE Slimbook

Planet Ubuntu - Thu, 01/26/2017 - 05:32

The past couple of months an elite team of KDE contributors worked on a top-secret project. Today we finally announced it to the public.

The KDE Slimbook

Together with the Spanish laptop retailer Slimbook we created our very first KDE laptop. It looks super slick and sports an ever so sexy KDE Slimbook logo on the back of the screen. It will initially come with KDE neon as operating system.

Naturally, as one of the neon developers, I was doing some software work to help this along. Last year already we switched to a more reliable graphics driver. Our installer got a face-lift to make it more visually appealing. The installer gained an actually working OEM installation mode. A hardware integration feature was added to our package pool to make sure the KDE Slimbook works perfectly out of the box.
The device looks and feels awesome. Plasma’s stellar look and feel complements it very well making for a perfect overall experience.

I am super excited and can’t wait for more people to get their hands on it, so we get closer to a world in which everyone has control over their digital life and enjoys freedom and privacy, thanks to KDE.

Stephan Adig: Dear OpenStack Foundation

Planet Ubuntu - Thu, 01/26/2017 - 02:39

why do I need to be an OpenStack Foundation Member when I want to send you a bugfix via PR on GitHub?

I don't wanna work on OpenStack per se, I just want to use one of your little utils from your stack and it doesn't work as expected under a newer version of Python :)

It would be nice, if the barrier to contribute could be lowered.

Meerkat: The Perfect C Array Library

Planet Ubuntu - Thu, 01/26/2017 - 01:38

I love C. And I loathe C++.

But there’s one thing I like about C++: The fact that I don’t have to write my own dynamic array libraries each time I try to start a project.

Of course, there are many libraries that exist for working with arrays in C. Glib, Eina, DynArray, etc. But I wanted something as easy to use as C++’s std::vector, with the performance and memory usage of std::vector.

By the way, I am not talking about algorithmic performance. I’m writing this assuming the algorithms are identical (i.e. I’m writing purely about implementation differences).

There is a few problems with the performance and memory usage of the aforementioned libraries, the major one being that the element size is stored as a structure member. Which means an extra 4-8 bytes per array, and constantly having to read a variable (which means many missed optimization opportunities). While this may not sound too bad (and in the grand scheme of things, probably isn’t), it is undeniably less efficient than C++.

This isn’t the only problem, there are other missed optimization opportunities in the function (vs macro)-based variants, for example, calling functions for tiny operations, calling memcpy for types that fit within registers, etc.

All of this might seem like splitting hairs, and it probably is. But knowing that C++ can be faster, more memory efficient, and less bothersome to code in than C is not a thought I like very much. So I wanted to try to level the playing field.

It took me a rather long amount of sporadic work for me to create my very own “Perfect C Array Library”, that, I thought, fulfilled my requirements.

First, let’s look at some example code using it:

array(int) myarray = array_init(); array_push(myarray, 5); array_push(myarray, 6); for (int i = 0; i < myarray.length; i++) { printf("%i\n", myarray.data[i]); } array_free(myarray);

Alright, it might be a tiny bit less pretty than C++. But hey, this is good enough for me.

In terms of performance and memory issues, I fixed the issues I wrote above. So in theory, it should be just as fast as C++, right?

Turns out I missed one issue. Cache Misses. In my mind, if everything was written as a macro, it would, in theory, be faster than functions. I was wrong. Large portions of code inlined can result in cache misses, which will quite negatively impact the performance of the function.

So, as far as I can see, it is impossible to write a set of array functions for C that will be as fast and easy to use as C++’s std::vector. But please correct me if I’m wrong!

With that being said, this implementation is the most efficient I’ve been able to write so far, so let me show you the idea behind it:

#define array(type) \ struct { \ type* data; \ size_t length; \ } #define array_init() \ { \ .data = NULL; \ .length = 0; \ } #define array_free(array) \ do { \ free(array.data); \ array.data = NULL; \ array.length = 0; \ } while (0) #define array_push(array, element) \ do { \ array.data = realloc(array.data, \ sizeof(*array.data) * \ (array.length + 1)); \ array.data[array.length] = element; \ array.length++; \ } while (0)

The magic is in sizeof(*array.data). For some reason I never knew this was legal in C, but it does exactly what it says it does: it returns the size of type. Which eliminates the need to store this in the struct.

The code above is oversimplified to demonstrate the idea. It’s very incomplete, algorithmically slow, and unsafe. But the idea is there.

To summarize, I am not aware of any way to write a completely zero-compromise array library in C, but the code above shows the closest I’ve come to that.

 

P.S. There is one problem I am aware of with this method:

array(int) myarray; array(int) myarray1 = myarray; /* 'error: invalid initializer' */

There are 2 ways to get around this:

memcpy(&myarray1, &myarray, sizeof(myarray)); /* or */ myarray1 = *((typeof(myarray1)*)&myarray); /* requires GNU C */

Both of which should, under a decent optimization level, result in the same assembly.


Timo Aaltonen: Mesa 12.0.6 in 16.04 & 16.10

Planet Ubuntu - Wed, 01/25/2017 - 22:13

Previous LTS point-releases came with a renamed Mesa backported from the latest release (as in mesa-lts-wily for instance) . Among other issues this prevented providing newer Mesa backports for point-release users without getting a mess of different versions. 

That’s why from 16.04.2 onwards Mesa will be backported unrenamed, and this time it is the last version of the 12.0.x series which was also used in 16.10. It’s available now in xenial-proposed, and of course in yakkety-proposed too (16.10 released with 12.0.3). Get it while hot! 


Stuart Langridge: We all sorta thought

Planet Ubuntu - Wed, 01/25/2017 - 17:08

A thing I wrote today, about Trump and Brexit and “post-truth” and “alternative facts” and helplessness, because I’ve had this conversation separately three times today.

this is the thing. We all sorta thought (and by “we” I mean everyone from us here right back to, I dunno, Newton and Boyle) that if we provided inductive or deductive proof of a thing, that everyone else would say “oh yeah, I’m convinced now!” and that’d be it. But people who don’t want that to happen have learned that attacking the evidence doesn’t work — it took them a few hundred years to learn that, but they did — but dismissing the whole idea as illegitimate does work. And we don’t know how to argue against that. I say two and two are four; you disagree; I say “no look here’s the proof”; you say “your methods of proof are wrong and biased”; and then I’m all, er, I don’t know what to say now, you were meant to be convinced by the proof.

more importantly: a third party, looking at that conversation, goes away thinking “well, is 2+2 equal to 4? Don’t know; there seem to be two sides to that argument”, or worse, “man, I just don’t care what 2+2 is because every time I try to find out there’s just loads of shouting, so I’ll stop asking”.

and thus, modern politics. Gaslighting and obfuscation, designed to make people believe that facts are disputable and that engagement is confusing and annoying.

(Of course, part of the problem here is that our side have a habit of declaring things to be an actual fact when they’re really “what we want to believe”, and once one’s cried wolf that way a few times, one’s credibility is gone and it’s really hard to get back. It’s not all the other side’s fault.)

Normally I wouldn’t re-post such a thing, but of course this conversation happened on Slack, which means that six months from now I won’t be able to link to this because it’ll be over 10,000 messages ago and Slack will be holding it to ransom until we pay money, and five years from now I won’t be able to link to it because Slack will have gone bust or have been sold to someone and shut down.

Xubuntu: Winners of the #lovexubuntu Competition!

Planet Ubuntu - Wed, 01/25/2017 - 13:53

As Xubuntu’s tenth anniversary year is now over, it’s time to announce the winners of the #lovexubuntu competition announced in June!

The two grand prize winners, receiving a t-shirt and a sticker set, are Keith I Myers with his Xubuntu cookie cutters and Daniel Eriksson with a story of a happy customer. The three other finalists, each one receiving a set of Xubuntu stickers are Dina, Sabrin Islam and Michael Morozov.

Congratulations to all winners!

Finally, before presenting the winning submissions, let us thank everybody who submitted a story or a picture – we really appreciate it! For those who want to see more, all of the submissions are listed on the Xubuntu wiki on the Love Xubuntu 2016 page.

The Grand Prize Winners Keith I Myers Xubuntu cookie cutters by Keith I Myers

After seeing a simple metal cookie cutter created by the Xubuntu Marketing lead, Keith was inspired to make a plastic 3D-printed version of the Xubuntu cookie cutter. He printed several of them and also shared the design on Thingiverse so others could also print it.

If you decide to print and use these, we’d love to see the resulting cookies!

Daniel Eriksson

We run a small business, mainly doing computer service and maintenance, app programming and other similar things. One of the things we do are customized Linux desktops, where we build a user interface based around a customers wishes; tweaking everything from themes, colors and fonts to panels, widgets and other content. When we started doing this we tried out and evaluated loads of distributions and desktop environments, eventually deciding that Xubuntu was the perfect choice. We wanted to maximize the amount of customization we could do while still having a system that was light on resources (since customers often have old computers.)

It was a choice we have never regretted, as it has always fit our needs perfectly. We can get everything from design to workflow just as we want it, and it is stable as rock while still often introducing new features for us to play with.

One of our best experiences was with a person who wanted an interface on a laptop that was just as simple and scaled down as that of an iPad, while still being able to do all things a computer ought to do. This was not an especially computer-savvy person, so it needed to be straightforward and simple. We managed to discard most classic desktop parameters and build a very unique interface, all within what was provided by stock Xubuntu. (Though we did some art ourselves.) It turned out great, our customer was very happy with it and other people have shown interest in having something similar on their computers. Needless to say, this was a success story for us which had not been possible without Xubuntu.

So thanks for all your hard work! We keep on designing our users desktops and will continue to use the excellent Xubuntu for it. :)

Finalists Dina

I live in Israel, and in Hebrew, the slang word “Zubi” is an insolent and extreme way to say “No way I’ll do it”.

Also, according to the Hebrew Wikipedia, Xubuntu is pronounced as “Zoo-boon-too” rather than “Ksoo-boon-too” (its name is written in Hebrew, which solves that ambiguity).

Therefore, when I told a friend that my old computer would not boot because of a hard disk problem, and all the technicians advised me to buy a new one, but I installed Xubuntu and it works, he noted that “Xubuntu” actually sounds like “I’m not doing that, I’m moving to Linux!”

Sabrin Islam

@Xubuntu A teacher once asked me, “how did you get Windows to look like that”, to which I replied it’s Xubuntu sir #LoveXubuntu

– @Ornim on Twitter
Original tweet Michael Morozov

I #LoveXubuntu because it’s top-notch, minimalistic neat and helps me focus on real things.

– @m1xo_0n on Twitter
Original tweet Beyond Year 10

As we look forward to 2017 and the 11th year of Xubuntu, keep an eye out for other ways you can help celebrate and promote Xubuntu. And as always, we could use more folks contributing directly to the development, testing and release of Xubuntu, see the Xubuntu Contributor Documentation to learn more.

Ubuntu Insights: Canonical Distribution of Kubernetes – Release 1.5.2

Planet Ubuntu - Tue, 01/24/2017 - 08:28

We’re proud to announce support for Kubernetes 1.5.2 in the Canonical Distribution of Kubernetes. This is a pure upstream distribution of Kubernetes, designed to be easily deployable to public clouds, on-premise (ie vsphere, openstack), bare metal, and developer laptops. Kubernetes 1.5.2 is a patch release comprised of mostly bugfixes, and we encourage you to check out the release notes.

Getting Started:

Here’s the simplest way to get a Kubernetes 1.5.2 cluster up and running on an Ubuntu 16.04 system:

sudo apt-add-repository ppa:juju/stable sudo apt-add-repository ppa:conjure-up/next</span> sudo apt update sudo apt install conjure-up conjure-up kubernetes

During the installation conjure-up will ask you what cloud you want to deploy on and prompt you for the proper credentials. If you’re deploying to local containers (LXD) see these instructions for localhost-specific considerations.

For production grade deployments and cluster lifecycle management it is recommended to read the full Canonical Distribution of Kubernetes documentation.

Home page: https://jujucharms.com/canonical-kubernetes/

Source code: https://github.com/juju-solutions/bundle-canonical-kubernetes

How to upgrade

With your kubernetes model selected, you can deploy the bundle to upgrade your cluster if on the 1.5.x series of kubernetes. At this time releases before 1.5.x have not been tested. Depending on which bundle you have previously deployed, run:

juju deploy canonical-kubernetes

or

juju deploy kubernetes-core

If you have made tweaks to your deployment bundle, such as deploying additional worker nodes as a different label, you will need to manually upgrade the components. The following command list assumes you have made no tweaks, but can be modified to work for your deployment.

juju upgrade-charm kubernetes-master juju upgrade-charm kubernetes-worker juju upgrade-charm etcd juju upgrade-charm flannel juju upgrade-charm easyrsa juju upgrade-charm kubeapi-load-balancer

This will upgrade the charm code, and the resources to kubernetes 1.5.2 release of the Canonical Distribution of Kubernetes.

New features:
  • Full support for Kubernetes v1.5.2.
General Fixes
  • #151 #187 It wasn’t very transparent to users that they should be using conjure-up when locally developing, conjure-up is now the defacto default mechanism for deploying CDK.

  • #173 Resolved permissions on ~/.kube on kubernetes-worker units

  • #169 Tuned the verbosity of the AddonTacticManager class during charm layer build process

  • #162 Added NO_PROXY configuration to prevent routing all requests through configured proxy [by @axinojolais]

  • #160 Resolved an error by flannel sometimes encountered during cni-relation-changed [by @spikebike]

  • #172 Resolved sporadic timeout issues between worker and apiserver due to nginx connection buffering [by @axinojolais]

  • #101 Work-around for offline installs attempting to contact pypi to install docker-compose

  • #95 Tuned verbosity of copy operations in the debug script for debugging the debug script.

Etcd layer-specific changes
  • #72 #70 Resolved a certificate-relation error where etcdctl would attempt to contact the cluster master before services were ready [by @javacruft]
Unfiled/un-scheduled fixes:
  • #190 Removal of assembled bundles from the repository. See bundle author/contributors notice below
Additional Feature(s):
  • We’ve open sourced our release management process scripts we’re using in a juju deployed jenkins model. These scripts contain the logic we’ve been running by hand, and give users a clear view into how we build, package, test, and release the CDK. You can see these scripts in the juju-solutions/kubernetes-jenkins repository. This is early work, and will continue to be iterated on / documented as we push towards the Kubernetes 1.6 release.
Notice to bundle authors and contributors:

The fix for #190 is a larger change that has landed in the bundle-canonical-kubernetes repository. Instead of maintaining several copies across several repositories of a single use-case bundle; we are now assembling the CDK based bundles as fragments (un-official nomenclature).

This affords us the freedom to rapidly iterate on a CDK based bundle and include partner technologies, such as different SDN vendors, Storage backend components, and other integration points. Keeping our CDK bundle succinct, and allowing the more complex solutions to be assembled easily, reliably, and repeatedly. This does change the contribution guidelines for end users.

Any changes to the core bundle should be placed in its respective fragment under the fragments directory. Once this has been placed/merged, the primary published bundles can be assembled by running ./bundle in the root of the repository. This process has been outlined in the repository README.md

We look forward to any feedback on how opaque/transparent this process is, and if it has any useful applications outside of our own release management process. The ./bundle python script is still very much geared towards our own release process, and how to assemble bundles targeted for the CDK. However we’re open to generalizing them and encourage feedback/contributions to make this more useful to more people.

How to contact us:

We’re normally found in these Slack channels and attend these sig meetings regularly:

Operators are an important part of Kubernetes, we encourage you to participate with other members of the Kubernetes community!

We also monitor the Kubernetes mailing lists and other community channels, feel free to reach out to us. As always, PRs, recommendations, and bug reports are welcome: https://github.com/juju-solutions/bundle-canonical-kubernetes

Jono Bacon: Endless Code and Mission Hardware Demo

Planet Ubuntu - Tue, 01/24/2017 - 05:35

Recently, I have had the pleasure of working with a fantastic company called Endless who are building a range of computers and a Linux-based operating system called Endless OS.

My work with them has primarily been involved in the community and product development of an initiative in which they are integrating functionality into the operating system that teaches you how to code. This provides a powerful platform where you can learn to code and easily hack on applications in the platform.

If this sounds interesting to you, I created a short video demo where I show off their Mission hardware as well as run through a demo of Endless Code in action. You can see it below:

I would love to hear what you think and how Endless Code can be improved in the comments below.

The post Endless Code and Mission Hardware Demo appeared first on Jono Bacon.

Ubuntu Weekly Newsletter Issue 495

The Fridge - Mon, 01/23/2017 - 19:24

Welcome to the Ubuntu Weekly Newsletter. This is issue #495 for the weeks January 9 – 22, 2017, and the full version is available here.

In this issue we cover:

The issue of The Ubuntu Weekly Newsletter is brought to you by:

  • Elizabeth K. Joseph
  • Chris Guiver
  • Paul White
  • And many others

If you have a story idea for the Weekly Newsletter, join the Ubuntu News Team mailing list and submit it. Ideas can also be added to the wiki!

Except where otherwise noted, content in this issue is licensed under a Creative Commons Attribution 3.0 License BY SA Creative Commons License

The Fridge: Ubuntu Weekly Newsletter Issue 495

Planet Ubuntu - Mon, 01/23/2017 - 19:24

Welcome to the Ubuntu Weekly Newsletter. This is issue #495 for the weeks January 9 – 22, 2017, and the full version is available here.

In this issue we cover:

The issue of The Ubuntu Weekly Newsletter is brought to you by:

  • Elizabeth K. Joseph
  • Chris Guiver
  • Paul White
  • And many others

If you have a story idea for the Weekly Newsletter, join the Ubuntu News Team mailing list and submit it. Ideas can also be added to the wiki!

Except where otherwise noted, content in this issue is licensed under a Creative Commons Attribution 3.0 License BY SA Creative Commons License

Ubuntu Insights: What IT Pros Need to Know about Server Provisioning

Planet Ubuntu - Mon, 01/23/2017 - 06:30

Big Software, IoT and Big Data are changing how organisations are architecting, deploying, and managing their infrastructure. Traditional models are being challenged and replaced by software solutions that are deployed across many environments and many servers. However, no matter what infrastructure you have, there are bare metal servers under it, somewhere.

Organisations are looking for more efficient ways to balance their hardware and infrastructure investments with the efficiencies of the cloud. Canonical’s MAAS (Metal As A Service) is such a technology. MAAS is designed for devops at scale, in places where bare metal is the best way to run your applications. Big data, private cloud, PAAS and HPC all thrive on MAAS. Hardware has always been an expensive and difficult resource to deploy within a data centre, but is unfortunately still a major consideration for any organisation moving all or part of their infrastructure to the cloud. To become more cost-effective, many organisations hire teams of developers to cobble together software solutions that solve functional business challenges while leveraging existing legacy hardware in the hopes of offsetting the need to buy and deploy more hardware-based solutions.

MAAS isn’t a new concept, but demand and adoption rates are growing because many enterprises want to combine the flexibility of cloud services with the raw power of bare metal servers to run high-power, scalable workloads. For example, when a new server needs to be deployed, MAAS automates most, if not all, of the provisioning process. Automation makes deploying solutions much quicker and more efficient because it allows tedious tasks to be performed faster and more accurately without human intervention. Even with proper and thorough documentation, manually deploying server to run web services or Hadoop, for example, could take hours compared to a few minutes with MAAS.

Forward thinking companies are leveraging server provisioning to combine the flexibility of the cloud with the power and security of hardware. For example:

  • High Performance Computing organisations are using MAAS to modernise how they deploy and allocate servers quickly and efficiently.
  • Smart Data centers are using MAAS to enable multi purpose their server usage to improve efficiency and ensure servers do not go underutilised.
  • Hybrid cloud providers leverage MAAS to provide extra server support during peak demand times and between various public cloud providers

This ebook: Server Provisioning: What Network Admins & IT Pros Need to Know outlines how innovative companies are leveraging MAAS to get more out of their hardware investment while making their cloud environments more efficient and reliable. Smart IT pros know that going to the cloud does not mean having to rip and replace their entire infrastructure to take advantage of the opportunities the cloud offers. Canonical’s MAAS is a mature solution to help organisations to take full advantage of their cloud and legacy hardware investments.

Get started with MAAS

To download and install MAAS for free please visit ubuntu.com/download/server-provisioning or to talk to one of our scale-out experts about deploying MAAS in your datacenter contact us. For more information please download our free eBook on MAAS.

Download eBook

Jorge Castro: Canonical Distribution of Kubernetes - Release 1.5.2

Planet Ubuntu - Mon, 01/23/2017 - 01:30

We’re proud to announce support for Kubernetes 1.5.2 in the Canonical Distribution of Kubernetes. This is a pure upstream distribution of Kubernetes, designed to be easily deployable to public clouds, on-premise (ie vsphere, openstack), bare metal, and developer laptops. Kubernetes 1.5.2 is a patch release comprised of mostly bugfixes, and we encourage you to check out the release notes.

Getting Started:

Here’s the simplest way to get a Kubernetes 1.5.2 cluster up and running on an Ubuntu 16.04 system:

sudo apt-add-repository ppa:juju/stable sudo apt-add-repository ppa:conjure-up/next sudo apt update sudo apt install conjure-up conjure-up kubernetes

During the installation conjure-up will ask you what cloud you want to deploy on and prompt you for the proper credentials. If you’re deploying to local containers (LXD) see these instructions for localhost-specific considerations.

For production grade deployments and cluster lifecycle management it is recommended to read the full Canonical Distribution of Kubernetes documentation.

Home page: https://jujucharms.com/canonical-kubernetes/

Source code: https://github.com/juju-solutions/bundle-canonical-kubernetes

How to upgrade

With your kubernetes model selected, you can deploy the bundle to upgrade your cluster if on the 1.5.x series of kubernetes. At this time releases before 1.5.x have not been tested. Depending on which bundle you have previously deployed, run:

    juju deploy canonical-kubernetes

or

    juju deploy kubernetes-core

If you have made tweaks to your deployment bundle, such as deploying additional worker nodes as a different label, you will need to manually upgrade the components. The following command list assumes you have made no tweaks, but can be modified to work for your deployment.

juju upgrade-charm kubernetes-master juju upgrade-charm kubernetes-worker juju upgrade-charm etcd juju upgrade-charm flannel juju upgrade-charm easyrsa juju upgrade-charm kubeapi-load-balancer

This will upgrade the charm code, and the resources to kubernetes 1.5.2 release of the Canonical Distribution of Kubernetes.

New features:
  • Full support for Kubernetes v1.5.2.
General Fixes
  • #151 #187 It wasn’t very transparent to users that they should be using conjure-up when locally developing, conjure-up is now the defacto default mechanism for deploying CDK.

  • #173 Resolved permissions on ~/.kube on kubernetes-worker units

  • #169 Tuned the verbosity of the AddonTacticManager class during charm layer build process

  • #162 Added NO_PROXY configuration to prevent routing all requests through configured proxy [by @axinojolais]

  • #160 Resolved an error by flannel sometimes encountered during cni-relation-changed [by @spikebike]

  • #172 Resolved sporadic timeout issues between worker and apiserver due to nginx connection buffering [by @axinojolais]

  • #101 Work-around for offline installs attempting to contact pypi to install docker-compose

  • #95 Tuned verbosity of copy operations in the debug script for debugging the debug script.

Etcd layer-specific changes
  • #72 #70 Resolved a certificate-relation error where etcdctl would attempt to contact the cluster master before services were ready [by @javacruft]
Unfiled/un-scheduled fixes:
  • #190 Removal of assembled bundles from the repository. See bundle author/contributors notice below
Additional Feature(s):
  • We’ve open sourced our release management process scripts we’re using in a juju deployed jenkins model. These scripts contain the logic we’ve been running by hand, and give users a clear view into how we build, package, test, and release the CDK. You can see these scripts in the juju-solutions/kubernetes-jenkins repository. This is early work, and will continue to be iterated on / documented as we push towards the Kubernetes 1.6 release.
Notice to bundle authors and contributors:

The fix for #190 is a larger change that has landed in the bundle-canonical-kubernetes repository. Instead of maintaining several copies across several repositories of a single use-case bundle; we are now assembling the CDK based bundles as fragments (un-official nomenclature).

This affords us the freedom to rapidly iterate on a CDK based bundle and include partner technologies, such as different SDN vendors, Storage backend components, and other integration points. Keeping our CDK bundle succinct, and allowing the more complex solutions to be assembled easily, reliably, and repeatedly. This does change the contribution guidelines for end users.

Any changes to the core bundle should be placed in its respective fragment under the fragments directory. Once this has been placed/merged, the primary published bundles can be assembled by running ./bundle in the root of the repository. This process has been outlined in the repository README.md

We look forward to any feedback on how opaque/transparent this process is, and if it has any useful applications outside of our own release management process. The ./bundle python script is still very much geared towards our own release process, and how to assemble bundles targeted for the CDK. However we’re open to generalizing them and encourage feedback/contributions to make this more useful to more people.

How to contact us:

We’re normally found in these Slack channels and attend these sig meetings regularly:

Operators are an important part of Kubernetes, we encourage you to participate with other members of the Kubernetes community!

We also monitor the Kubernetes mailing lists and other community channels, feel free to reach out to us. As always, PRs, recommendations, and bug reports are welcome: https://github.com/juju-solutions/bundle-canonical-kubernetes

Pages

Subscribe to Ubuntu Arizona LoCo Team aggregator