Most recent items from Ubuntu feeds:
The Fridge: Ubuntu Weekly Newsletter Issue 500 from Planet Ubuntu

Welcome to the Ubuntu Weekly Newsletter. This is issue #500 for the week February 20 – 26, 2017, and the full version is available here.
In this issue we cover:

Welcome to Issue 500
Words of Thanks
Congratulations Issue 500 Quiz Winners!
Zesty Zapus Beta 1 Released
Ubuntu Stats
UbuCon Summit Comes to Pasadena this Week!
LoCo Events
Simon Raffeiner: Basic management of an Ubuntu Core installation
Harald Sitter: Plasma in a Snap?
Dustin Kirkland: The Questions that You’re Afraid to Ask about Containers
Elizabeth K. Joseph: Moving on from the Ubuntu Weekly Newsletter
Martin Pitt: systemd 233 about to be released, please help testing
Canonical News
In The Press
In The Blogosphere
Full Circle Magazine #118
S10E00 – Cool Skillful Title – Ubuntu Podcast
Weekly Ubuntu Development Team Meetings
Upcoming Meetings and Events
Updates and Security for 12.04, 14.04, 16.04 and 16.10
And much more!

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

Paul White
Chris Guiver
Elizabeth K. Joseph
Vishnu Narayanan
David Morfin
Jim Connett
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

about 8 hours ago

Ubuntu Insights: Mobile World Congress 2017, Day One Recap from Planet Ubuntu

It’s the last week of February and that can only mean one thing, Mobile World Congress (MWC) in Barcelona, Spain.  This event, unlike other mega shows, has stood the test of time and has maintained its title as the premier telecom, device, and Internet of Things (IoT) conference in the world. For the past several years, MWC has positioned 5G front and centre for the future of the industry, 2017 is no exception.  We are quickly moving into an era where the industry has begun moving towards a more orchestrated ecosystem of ‘things’ – devices, machines, sensors, vehicles, wearables, etc.  This shift is forcing network service providers to build-out their networks to become more customer-focused and deploy services that will thrive in the ‘things’ ecosystem.  This shift is also creating immediate challenges for network providers due to the increased demand for bandwidth and connectivity.  At Canonical, we call it “Software-defined Everything”.
In the era of things, communications companies are working hard to keep pace with the transmission and storage of the massive amounts of personal information this new world brings.  At MWC 2017 there is an increased focus on what more organisations can do to protect against highly sophisticated cyber-attacks, fraud, and to improve privacy.  Machine learning, Artificial Intelligence (AI), and even cognitive ,computing solutions have extended their presence as a way to help companies begin tackling security problems by detecting anomalies and patterns that indicate attacks or fraud.  Moreover, AI is presenting new opportunities for communications companies to improve overall efficiencies, improve customer service, and drive revenue.
The telecommunications industry has been slow when responding to the competitive pressure put on them by public cloud. Platforms like OpenStack (Infrastructure as a Service), MAAS (Metal as a Service – server provisioning), and Juju (model driven operations) demonstrate Canonical’s promise to helping telecom service providers and enterprises to become more successful in the digital economy.  This year, Canonical is showcasing at our booth (3K31 – Hall P3, Level 0) innovation around process (Docker) and machine containers (LXD) on OpenStack with Kubernetes, Software Defined Networking (SDN), 5G, and Network Functions Virtualization (NFV)/Virtual Network Function (VNF), etc.
Visitors to the Ubuntu booth will have the ability to interact with and see live commercial deployments of several solutions including:
Augmented Reality
The DAQRI Smart Helmet, powered by an Ubuntu AR application, provides an augmented reality experience that can be used in industrial settings and brings to life all the data generated by the new world of Industrial Internet of Things. By overlaying data onto the display, thermal anomalies can be quickly identified and operators and technicians can deliver faster Mean Time to Repair (MTTR).

Software Defined Radios
In the beginning of 2016 it looked impossible that software defined radio would be viable. The collaboration between Lime Micro has changed that. The LimeSDR is the first software defined radio that can be programmed via open source apps, called snaps, that anybody can download from an app store. There are now thousands of developers who have or shortly will receive their LimeSDR. They will be able to create all types of protocols and share them among the community. LTE, LoRa, Bluetooth, ZigBee and many more. Even invent their own protocols.

Digital Signage
Screenly 2 digital signage solution builds on the vision of the original, making interactive digital signage easy to use and accessible to organisations of all sizes. Built on Ubuntu Core and Raspberry Pi 3, organizations can deploy 1080p HD video, web content, public message and point of sale materials.

In addition to our communications solutions, we are highlighting many innovative IoT, Consumer Premise Equipment (CPE), and other edge device solutions for smart homes, robots, drones, and wearables.  Ubuntu has become the de facto operating system and platform for developing IoT solutions that offer a converged experience across mobile devices, PCs, and tablets.

One of the coolest things about MWC 2017 is everything we’re demonstrating in our booth (3K31 – Hall P3, Level 0) is directly relevant to the pain points emphasised time and time again in every panel, tour, or breakout sessions that I attended. Many of the visitors to our booth were interested speaking to our booth experts about our leadership with containers and the Canonical Distribution of Kubernetes, success with deploying or hosting OpenStack, the power of Ubuntu with devices and IoT, and insights on improving overall IT operations efficiency via MAAS or Juju.
If you’re at MWC 2017 and you haven’t visited us yet, please come by! If you aren’t here, follow us on Twitter @ubuntu, @ubuntucloud for tweets all week long.

about 12 hours ago

Stéphane Graber: LXD 2.0: Debugging and contributing to LXD [12/12] from Planet Ubuntu

This is the twelfth and last blog post in this series about LXD 2.0.

Introduction
This is finally it! The last blog post in this series of 12 that started almost a year ago.
If you followed the series from the beginning, you should have been using LXD for quite a bit of time now and be pretty familiar with its day to day operation and capabilities.
But what if something goes wrong? What can you do to track down the problem yourself? And if you can’t, what information should you record so that upstream can track down the problem?
And what if you want to fix issues yourself or help improve LXD by implementing the features you need? How do you build, test and contribute to the LXD code base?
Debugging LXD & filing bug reports
LXD log files
/var/log/lxd/lxd.log
This is the main LXD log file. To avoid filling up your disk very quickly, only log messages marked as INFO, WARNING or ERROR are recorded there by default. You can change that behavior by passing “–debug” to the LXD daemon.
/var/log/lxd/CONTAINER/lxc.conf
Whenever you start a container, this file is updated with the configuration that’s passed to LXC.
This shows exactly how the container will be configured, including all its devices, bind-mounts, …
/var/log/lxd/CONTAINER/forkexec.log
This file will contain errors coming from LXC when failing to execute a command.
It’s extremely rare for anything to end up in there as LXD usually handles errors much before that.
/var/log/lxd/CONTAINER/forkstart.log
This file will contain errors coming from LXC when starting the container.
It’s extremely rare for anything to end up in there as LXD usually handles errors much before that.
CRIU logs (for live migration)
If you are using CRIU for container live migration or live snapshotting there are additional log files recorded every time a CRIU dump is generated or a dump is restored.
Those logs can also be found in /var/log/lxd/CONTAINER/ and are timestamped so that you can find whichever matches your most recent attempt. They will contain a detailed record of everything that’s dumped and restored by CRIU and are far better for understanding a failure than the typical migration/snapshot error message.
LXD debug messages
As mentioned above, you can switch the daemon to doing debug logging with the –debug option.
An alternative to that is to connect to the daemon’s event interface which will show you all log entries, regardless of the configured log level (even works remotely).
An example for “lxc init ubuntu:16.04 xen” would be:
lxd.log:
INFO[02-24|18:14:09] Starting container action=start created=2017-02-24T23:11:45+0000 ephemeral=false name=xen stateful=false used=1970-01-01T00:00:00+0000
INFO[02-24|18:14:10] Started container action=start created=2017-02-24T23:11:45+0000 ephemeral=false name=xen stateful=false used=1970-01-01T00:00:00+0000
lxc monitor –type=logging:
metadata:
context: {}
level: dbug
message: 'New events listener: 9b725741-ffe7-4bfc-8d3e-fe620fc6e00a'
timestamp: 2017-02-24T18:14:01.025989062-05:00
type: logging

metadata:
context:
ip: '@'
method: GET
url: /1.0
level: dbug
message: handling
timestamp: 2017-02-24T18:14:09.341283344-05:00
type: logging

metadata:
context:
driver: storage/zfs
level: dbug
message: StorageCoreInit
timestamp: 2017-02-24T18:14:09.341536477-05:00
type: logging

metadata:
context:
ip: '@'
method: GET
url: /1.0/containers/xen
level: dbug
message: handling
timestamp: 2017-02-24T18:14:09.347709394-05:00
type: logging

metadata:
context:
ip: '@'
method: PUT
url: /1.0/containers/xen/state
level: dbug
message: handling
timestamp: 2017-02-24T18:14:09.357046302-05:00
type: logging

metadata:
context: {}
level: dbug
message: 'New task operation: 2e2cf904-c4c4-4693-881f-57897d602ad3'
timestamp: 2017-02-24T18:14:09.358387853-05:00
type: logging

metadata:
context: {}
level: dbug
message: 'Started task operation: 2e2cf904-c4c4-4693-881f-57897d602ad3'
timestamp: 2017-02-24T18:14:09.358578599-05:00
type: logging

metadata:
context:
ip: '@'
method: GET
url: /1.0/operations/2e2cf904-c4c4-4693-881f-57897d602ad3/wait
level: dbug
message: handling
timestamp: 2017-02-24T18:14:09.366213106-05:00
type: logging

metadata:
context:
driver: storage/zfs
level: dbug
message: StoragePoolInit
timestamp: 2017-02-24T18:14:09.369636451-05:00
type: logging

metadata:
context:
driver: storage/zfs
level: dbug
message: StoragePoolCheck
timestamp: 2017-02-24T18:14:09.369771164-05:00
type: logging

metadata:
context:
container: xen
driver: storage/zfs
level: dbug
message: ContainerMount
timestamp: 2017-02-24T18:14:09.424696767-05:00
type: logging

metadata:
context:
driver: storage/zfs
name: xen
level: dbug
message: ContainerUmount
timestamp: 2017-02-24T18:14:09.432723719-05:00
type: logging

metadata:
context:
container: xen
driver: storage/zfs
level: dbug
message: ContainerMount
timestamp: 2017-02-24T18:14:09.721067917-05:00
type: logging

metadata:
context:
action: start
created: 2017-02-24 23:11:45 +0000 UTC
ephemeral: "false"
name: xen
stateful: "false"
used: 1970-01-01 00:00:00 +0000 UTC
level: info
message: Starting container
timestamp: 2017-02-24T18:14:09.749808518-05:00
type: logging

metadata:
context:
ip: '@'
method: GET
url: /1.0
level: dbug
message: handling
timestamp: 2017-02-24T18:14:09.792551375-05:00
type: logging

metadata:
context:
driver: storage/zfs
level: dbug
message: StorageCoreInit
timestamp: 2017-02-24T18:14:09.792961032-05:00
type: logging

metadata:
context:
ip: '@'
method: GET
url: /internal/containers/23/onstart
level: dbug
message: handling
timestamp: 2017-02-24T18:14:09.800803501-05:00
type: logging

metadata:
context:
driver: storage/zfs
level: dbug
message: StoragePoolInit
timestamp: 2017-02-24T18:14:09.803190248-05:00
type: logging

metadata:
context:
driver: storage/zfs
level: dbug
message: StoragePoolCheck
timestamp: 2017-02-24T18:14:09.803251188-05:00
type: logging

metadata:
context:
container: xen
driver: storage/zfs
level: dbug
message: ContainerMount
timestamp: 2017-02-24T18:14:09.803306055-05:00
type: logging

metadata:
context: {}
level: dbug
message: 'Scheduler: container xen started: re-balancing'
timestamp: 2017-02-24T18:14:09.965080432-05:00
type: logging

metadata:
context:
action: start
created: 2017-02-24 23:11:45 +0000 UTC
ephemeral: "false"
name: xen
stateful: "false"
used: 1970-01-01 00:00:00 +0000 UTC
level: info
message: Started container
timestamp: 2017-02-24T18:14:10.162965059-05:00
type: logging

metadata:
context: {}
level: dbug
message: 'Success for task operation: 2e2cf904-c4c4-4693-881f-57897d602ad3'
timestamp: 2017-02-24T18:14:10.163072893-05:00
type: logging
The format from “lxc monitor” is a bit different from what you’d get in a log file where each entry is condense into a single line, but more importantly you see all those “level: dbug” entries
Where to report bugs
LXD bugs
The best place to report LXD bugs is upstream at https://github.com/lxc/lxd/issues.
Make sure to fill in everything in the bug reporting template as that information saves us a lot of back and forth to reproduce your environment.
Ubuntu bugs
If you find a problem with the Ubuntu package itself, failing to install, upgrade or remove. Or run into issues with the LXD init scripts. The best place to report such bugs is on Launchpad.
On an Ubuntu system, you can do so with: ubuntu-bug lxd
This will automatically include a number of log files and package information for us to look at.
CRIU bugs
Bugs that are related to CRIU which you can spot by the usually pretty visible CRIU error output should be reported on Launchpad with: ubuntu-bug criu
Do note that the use of CRIU through LXD is considered to be a beta feature and unless you are willing to pay for support through a support contract with Canonical, it may take a while before we get to look at your bug report.
Contributing to LXD
LXD is written in Go and hosted on Github.
We welcome external contributions of any size. There is no CLA or similar legal agreement to sign to contribute to LXD, just the usual Developer Certificate of Ownership (Signed-off-by: line).
We have a number of potential features listed on our issue tracker that can make good starting points for new contributors. It’s usually best to first file an issue before starting to work on code, just so everyone knows that you’re doing that work and so we can give some early feedback.
Building LXD from source
Upstream maintains up to date instructions here: https://github.com/lxc/lxd#building-from-source
You’ll want to fork the upstream repository on Github and then push your changes to your branch. We recommend rebasing on upstream LXD daily as we do tend to merge changes pretty regularly.
Running the testsuite
LXD maintains two sets of tests. Unit tests and integration tests. You can run all of them with:
sudo -E make check
To run the unit tests only, use:
sudo -E go test ./...
To run the integration tests, use:
cd test
sudo -E ./main.sh
That latter one supports quite a number of environment variables to test various storage backends, disable network tests, use a ramdisk or just tweak log output. Some of those are:

LXD_BACKEND: One of “btrfs”, “dir”, “lvm” or “zfs” (defaults to “dir”)
Lets your run the whole testsuite with any of the LXD storage drivers.
LXD_CONCURRENT: “true” or “false” (defaults to “false”)
This enables a few extra concurrency tests.
LXD_DEBUG: “true” or “false” (defaults to “false”)
This will log all shell commands and run all LXD commands in debug mode.
LXD_INSPECT: “true” or “false” (defaults to “false”)
This will cause the testsuite to hang on failure so you can inspect the environment.
LXD_LOGS: A directory to dump all LXD log files into (defaults to “”)
The “logs” directory of all spawned LXD daemons will be copied over to this path.
LXD_OFFLINE: “true” or “false” (defaults to “false”)
Disables any test which relies on outside network connectivity.
LXD_TEST_IMAGE: path to a LXD image in the unified format (defaults to “”)
Lets you use a custom test image rather than the default minimal busybox image.
LXD_TMPFS: “true” or “false” (defaults to “false”)
Runs the whole testsuite within a “tmpfs” mount, this can use quite a bit of memory but makes the testsuite significantly faster.
LXD_VERBOSE: “true” or “false” (defaults to “false”)
A less extreme version of LXD_DEBUG. Shell commands are still logged but –debug isn’t passed to the LXC commands and the LXD daemon only runs with –verbose.

The testsuite will alert you to any missing dependency before it actually runs. A test run on a reasonably fast machine can be done under 10 minutes.
Sending your branch
Before sending a pull request, you’ll want to confirm that:

Your branch has been rebased on the upstream branch
All your commits messages include the “Signed-off-by: First Last <email>” line
You’ve removed any temporary debugging code you may have used
You’ve squashed related commits together to keep your branch easily reviewable
The unit and integration tests all pass

Once that’s all done, open a pull request on Github. Our Jenkins will validate that the commits are all signed-off, a test build on MacOS and Windows will automatically be performed and if things look good, we’ll trigger a full Jenkins test run that will test your branch on all storage backends, 32bit and 64bit and all the Go versions we care about.
This typically takes less than an hour to happen, assuming one of us is around to trigger Jenkins.
Once all the tests are done and we’re happy with the code itself, your branch will be merged into master and your code will be in the next LXD feature release. If the changes are suitable for the LXD stable-2.0 branch, we’ll backport them for you.
Conclusion
I hope this series of blog post has been helpful in understanding what LXD is and what it can do!
This series’ scope was limited to the LTS version of LXD (2.0.x) but we also do monthly feature releases for those who want the latest features. You can find a few other blog posts covering such features listed in the original LXD 2.0 series post.
Extra information
The main LXD website is at: https://linuxcontainers.org/lxd
Development happens on Github at: https://github.com/lxc/lxd
Mailing-list support happens on: https://lists.linuxcontainers.org
IRC support happens in: #lxcontainers on irc.freenode.net
Try LXD online: https://linuxcontainers.org/lxd/try-it

about 14 hours ago

Ubuntu Insights: The no-nonsense way to accelerate your business with containers from Planet Ubuntu

Container technology has brought about a step-change in virtualisation technology. Organisations implementing containers see considerable opportunities to improve agility, efficiency, speed, and manageability within their IT environments. Containers promise to improve datacenter efficiency and performance without having to make additional investments in hardware or infrastructure.
Traditional hypervisors provide the most common form of virtualisation, and virtual machines running on such hypervisors are pervasive in nearly every datacenter.
Containers offer a new form of virtualisation, providing almost equivalent levels of resource isolation as a traditional hypervisor. However, containers are lower overhead both in terms of a smaller memory footprint and better efficiency. This means higher density can be achieved – simply put, you can get more for the same hardware.

Our latest white paper, For CTOs: the no-nonsense way to accelerate your business with containers, explains the background and timeline to the development of containers, and the most recent technology that has led to the proliferation of containers on the Linux platform. It explains the differences between, advantages, and disadvantages of both process and machine containers. It examines the two main software tools (Docker and LXD) that are used to manipulate containers. Lastly, a glossary at the end of the paper provides a convenient reference point for the technical terms used within the paper.
Canonical, the company behind the Ubuntu operating system, is intimately involved in the development of Linux containers. LXD machine containers is a Canonical-initiated project and Canonical employs several of the lead container developers as well as the overall LXD project leader. Further, Canonical has also developed fan networking, a technique to handle efficiently the challenges in IP address management and overlay networks created by the proliferation of IP addresses consequent upon the increased virtualisation density that containers provide.
Canonical’s Ubuntu operating system underpins most container initiatives, including over 70% of Docker containers in use today. Moreover, Microsoft’s Azure Kubernetes service is built on Ubuntu and in partnership with Google, Canonical has released its own distribution of Kubernetes. Canonical is an active partner in all the leading container initiatives, including Docker, and is a member of the Cloud Native Compute Foundation.
Containers present a new opportunity for the CTO to reduce cost, to increase agility, and to move to a more scalable and resilient architecture. However, CTOs must also recognise that some use cases are better suited to containers than others, that grasping this opportunity requires a recognition of transition costs, and that in some cases this change in infrastructure also brings some challenges. These concepts are more fully explained in this white paper.
Download whitepaper

about 16 hours ago

Simos Xenitellis: How to make a snap package for lolcat with snapcraft on Ubuntu from Planet Ubuntu

In this post we are going to see how to make snap installation packages for a program called lolcat.
What you need for this tutorial? This tutorial is similar to Snap a python application. If you first follow that tutorial, then this one will reinforce what you have learned and expand to dealing with more programming languages than just Python.
What will you learn?

How to deal with different source code repositories and get into the process of snapping them in a snap (pun intended).
How to use the Snapcraft plugins for Python, golang, Rust and C/C++.
How to deal with confinement decisions and when to select strict confinement or classic confinement.
How to test the quality of an app before releasing to the Ubuntu Store
What is this true–color terminal emulator thing, what is lolcat and why it is cool (at least to a select few).

True-color terminal emulators
Terminal emulators like GNOME Terminal support the facility to display text in different colors.

You know this already because by default in Ubuntu you can see filenames in different colors, depending on whether they are executable (green), a directory (blue), a symbolic link (cyan) and so on. If you go 20+ years in the past, even the Linux console supported since then 256 colors.
What changed recently in terms of colors in the terminal emulators, is that newer terminal emulators support 16 million colors; what is described as true-color.

Here is an AWK script (of all scripting languages!) that shows a smooth gradient, from red to green to blue. In old terminal emulators and the Linux console, they were escape sequences to specify the colors, and you had to specify them by name. With the recent improvement among terminal emulators, it is now possible to specify the color by RGB value, thus 256*256*256 ~= 16 million different colors. You can read more about this in the article True Colour (16 million colours) support in various terminal applications and terminals. I found that AWK script there in this article. Try it one your Ubuntu as well!
Now, there is this Unix command called cat, which is used to print the contents of a text file in the terminal. cat /etc/passwd would show the contents of /etc/passwd. So, some people wrote an improved cat, called lolcat, that shows the content of files in a rainbow of colors.

In the screenshot above, the utility lolcat (a version we made and call lolcat-go) is used as a filter to a command (snapcraft –help), and colorizes the text that it receives with a nice rainbow of colors.
In practice, the lolcat utility merely sets the color for each character being printed. It starts with a random color and circles around the rainbow, heading diagonally towards the bottom-right. In the screenshot above, you can see the text snapcraft and Usage: in strong blue, and then diagonally (heading to bottom-right), the colors shift to green and then to orange.
Select which repositories to snap
The first implementation of the lolcat rainbow utility was probably by busyloop, written in Ruby. Since then, several others re-implemented lolcat into more programming languages. In this post we are going to snap:

The Python lolcat by tehmaze.
The golang lolcat by cezarsa.
The Rust lolcat by ur0 (a version that uses Rust’s concurrency feature!)
The C lolcat by jaseg (a version optimized for speed!)

Here we can see a) the URL of the source code, the available b) branches and c) tags. This is useful in the next section when we instruct Snapcraft which version of the source code to use.
In terms of versions among the four implementations, the Python lolcat has a recent tag 0.44, therefore we are using this tag and specify a version 0.44. For the rest, we are using the latest (master) checkout of their repositories, so we use the current date as a version number, in the form YYYYMMDD (for example, 20170226).
Completing the snapcraft.yaml metadata
When creating a snap, we need to write up a nice snap summary (less than 80 characters) and a description (less than 100 words). The summary will look like lolcat-python utility written in Python, and the description lolcat is a utility similar to the Unix “cat” command. lolcat adds rainbow colors to the text output.
In addition, we need suitable names for the four snaps. We are going to use lolcat-python, lolcat-go, lolcat-rust, and lolcat-c for each one of the four snaps.
All in all, here is the information we collected so far:

Python: name is “lolcat-python“, version is “0.44“, summary: lolcat-python utility written in Python, description: lolcat-python is a utility similar to the Unix “cat” command. lolcat-python adds rainbow colors to the text output.
Go: name is “lolcat-go“, version is “20170226“, summary: lolcat-go utility written in Go, description: lolcat-go is a utility similar to the Unix “cat” command. lolcat-go adds rainbow colors to the text output.
Rush: name is “lolcat-rust“, version is “20170226“, summary: lolcat-rust utility written in Rust, description: lolcat-rust is a utility similar to the Unix “cat” command. lolcat-rust adds rainbow colors to the text output.
C: name is “lolcat-c“, version is “20170226“, summary: lolcat-c utility written in C, description: lolcat-c is a utility similar to the Unix “cat” command. lolcat-c adds rainbow colors to the text output.

The final part in the metadata is the grade (whether it is devel or stable) and the confinement (whether it is devmode, classic or strict).
We select stable as the grade because we aim to add these snaps to the Ubuntu Store. If the grade is specified as devel, then the corresponding snap cannot be added to the stable channel (publicly available to all) of the Ubuntu Store. There is a section below on testing the four lolcat implementations and we will set accordingly the grade to either stable or devel, depending on the outcome of these tests.
We select initially devmode (DEVeloper MODE) as the confinement in order not to confine initially out snap. If our snap fails to run, we want to be sure it is some issue with our settings and not a byproduct of the choice of a stricter confinement. Once the snap can be built and run successfully, we change the confinement to either strict or classic and deal at that point with any issues that appear from there on.

Here is how the metadata look in the snapcraft.yaml configuration file for the Python variant of the snap.
Up to this point, all four snapcraft.yaml files, with metadata filled in, can be found at https://github.com/simos/lolcat-snap/tree/v1.0
Working on the “parts” section in snapcraft.yaml
We completed the easy metadata section, now it is time to work on the parts: section of snapcraft.yaml. (After the parts: section work, we just need the apps: section, where we expose the generated executable to the users of the snap).
Initially, snapcraft init will generate a stock snapcraft.yaml file, which has a stub parts: section. Here it how it looks,
parts:
  my-part:
    # See 'snapcraft plugins'
    plugin: nil
It defines the start of the parts: section. Then, a name, my-part: (we choose this name) is defined. Finally, the contents of my-part: are listed, here in two lines. The first line of my-part: is a comment (starts with #) and the second specifies the plugin, which is nil (it is reserved, and does nothing).
Note how these lines are aligned vertically. First is parts: at the start of the line, then two columns further, is my-part:. Then, two more columns further, we get the comment and the plugin: directive, both on the same column. We use spaces and not tabs. If you get any errors later on, check that you follow properly the formatting. You can have the levels separated by more than two columns, if you wish. But make sure that the same level lines are aligned on the same column.
Let’s figure out the initial versions of the parts:. Let’s do Python first!
parts:
  lolcat-python:
    source: https://github.com/tehmaze/lolcat.git
    source-tag: '0.44'
    plugin: python
We used the name lolcat-python: (our choice) for the name of this parts:. In there, we specify the source: for the source code repository, and any branches or tags that may be relevant. As we saw above, we work on the 0.44 tag. Finally, the source is written in Python, and we select the python plugin. (We will figure out later if we need to specify which of Python 2 or Python 3, if we get a relevant error).
Here is the Go,
parts:
  lolcat-go:
    source: https://github.com/cezarsa/glolcat.git
    plugin: go
Fairly expected. We do not specify a version, therefore it will use the latest snapshot of the source at the time of running snapcraft. We chose the name locat-go, and the golang plugin is called go.
Time for Rust,
parts:
  lolcat-rust:
    source: https://github.com/ur0/lolcat.git
    plugin: rust
Again, very similar to the above. We do not specify a specific source code version (there isn’t any tag or stable branch in the repository). We chose the name lolcat-rust, and the Rust plugin in snapcraft is called rust.
Finally, the version written in C,
parts:
  lolcat-c:
    source: https://github.com/jaseg/lolcat.git
    plugin: make
Again, we chose a name for this part, and it’s lolcat-c. Then, specified the URL for the source code. As for the plugin, we wrote make, although the source is written in C. Actually, the plugin: directive specifies how to build the source code. The make plugin does the make; make install sequence for us, and it’s our first choice when we see an existing Makefile file in a repository.
At this stage, we have four initial versions of configuration files. We are ready to try them out and deal with any errors that may appear.
Working on the Python version
Here is the configuration (snapcraft.yaml) for the Python variant up to this point,
name: lolcat-python
version: '0.44'
summary: lolcat utility written in Python
description: |
  lolcat-python is a utility similar to the Unix "cat" command.
  lolcat-python adds rainbow colors to the text output.
  The source code is available at https://github.com/tehmaze/lolcat

grade: stable
confinement: devmode

parts:
  lolcat-python:
    source: https://github.com/tehmaze/lolcat.git
    source-tag: '0.44'
    plugin: python
Let’s run snapcraft prime. The prime parameter will perform the necessary compilation and will put the result in the prime/ subdirectory. Since snapcraft prime does only the initial compilation steps, it is more convenient to use for repeated tests. Once it works with snapcraft prime, we would be ready in a single extra step to produce the final .snap file (by running snapcraft, no parameters).
$ snapcraft prime
Preparing to pull lolcat-python
[...]
Pulling lolcat-python
[...]
Installing collected packages: pip, six, pyparsing, packaging, appdirs, setuptools, wheel
[...]
Successfully downloaded lolcat
Preparing to build lolcat-python
Building lolcat-python
[...]
Successfully built lolcat
[...]
Successfully installed lolcat-0.44
Staging lolcat-python
Priming lolcat-python
$ _
It worked beautifully! Any result is in the prime/ subdirectory, and we can identify even the executable.
$ ls prime/
bin/  etc/  lib/  meta/  snap/  usr/
$ ls prime/bin
lolcat*
$ _
We are now ready to create the apps: section of the snapcraft.yaml configuration file, in order to expose the executable to the users,
apps:
  lolcat-python:
    command: lolcat
The name: of this snap is lolcat-python, and the name we chose in the apps: section is the same, lolcat-python. Since they are the same, once we install the snap, the newly available command will be called lolcat-python. If there was a difference between the two (for example, name: lolcat-python and apps: lolcat: […], then the command for the users would end up being something like lolcat-python.lolcat, which may not be desirable.
Working on the Go version
Here is the configuration (snapcraft.yaml) for the Go variant up to this point,
name: lolcat-go
version: '20170226'
summary: lolcat utility written in golang
description: |
  lolcat-go is a utility similar to the Unix "cat" command.
  lolcat-go adds rainbow colors to the text output.
  The source code is available at https://github.com/cezarsa/glolcat

grade: devel
confinement: devmode

parts:
  lolcat-go:
    source: https://github.com/cezarsa/glolcat.git
    plugin: go
Let’s run snapcraft prime and see how it goes.
$ snapcraft prime
Preparing to pull lolcat-go
[...]
Building lolcat-go
[...]Staging lolcat-go
Priming lolcat-go
$ ls prime/bin/
glolcat.git
$ _
Lovely! The go plugin managed to make sense of the repository and compile the Go version of lolcat. The generated executable is called glolcat.git. Therefore, the apps: section looks like
apps:
  lolcat-go:
    command: glolcat.git
In this way, once we install the Go snap of lolcat, there will be an executable lolcat-go exposed to the users. This executable will be the glolcat.git that was generated by the Snapcraft go plugin in prime/bin/. Snapcraft tries to find the final executable in either prime/ or prime/bin/, therefore we do not need to specify specifically bin/glolcat.git.
Working on the Rust version
Here is the configuration (snapcraft.yaml) for the Rust variant up to this point,
name: lolcat-rust
version: '20170226'
summary: lolcat utility written in Rust
description: |
  lolcat-rust is a utility similar to the Unix "cat" command.
  lolcat-rust adds rainbow colors to the text output.
  The source code is available at https://github.com/ur0/lolcat

grade: stable
confinement: devmode

parts:
  lolcat-rust:
    source: https://github.com/ur0/lolcat.git
    plugin: rust
Let’s run snapcraft prime and see how it goes.
$ snapcraft prime
Preparing to pull lolcat-rust
[...]
Downloading 'rustup.sh'[================] 100%
[...]
Preparing to build lolcat-rust
Building lolcat-rust
[...]
Staging lolcat-rust
Priming lolcat-rust
$ ls prime/bin/
lolcat
$ _
Without a hitch! The rust plugin noticed that we do not have the Rust compiler, and downloaded it for us! Then, it completed the compilation and the final executable is called lolcat. Therefore, the apps: section looks like
apps:
  lolcat-rust:
    command: lolcat
The apps: section will expose the generated lolcat executable by the name lolcat-rust. Since the name: field is also lolcat-rust, the resulting executable once we install the snap will be lolcat-rust as well. Again, Snapcraft looks by default into both prime/ and prime/bin/ for the command:, therefore it is not required to write specifically command: bin/lolcat.
Working on the C (make) version
Here is the configuration (snapcraft.yaml) for the C (using Makefile) variant up to this point,
name: lolcat-c
version: '20170226'
summary: lolcat utility written in C
description: |
  lolcat-c is a utility similar to the Unix "cat" command.
  lolcat-c adds rainbow colors to the text output.
  The source code is available at https://github.com/jaseg/lolcat

grade: stable
confinement: devmode

parts:
  lolcat-c:
    source: https://github.com/jaseg/lolcat.git
    plugin: make
Let’s run snapcraft prime and see how it goes.
$ snapcraft prime
Preparing to pull lolcat-c
Pulling lolcat-c
[...]
Submodule 'memorymapping' (https://github.com/NimbusKit/memorymapping) registered for path 'memorymapping'
Submodule 'musl' (git://git.musl-libc.org/musl) registered for path 'musl'
Cloning into 'memorymapping'...
[...]
Cloning into 'musl'...
[...]
Building lolcat-c
make -j4
"Using musl at musl"
cd musl; ./configure
[...]sh tools/musl-gcc.specs.sh "/usr/local/musl/include" "/usr/local/musl/lib" "/lib/ld-musl-x86_64.so.1" > lib/musl-gcc.specs
printf '#!/bin/sh\nexec "${REALGCC:-gcc}" "$@" -specs "%s/musl-gcc.specs"\n' "/usr/local/musl/lib" > tools/musl-gcc
chmod +x tools/musl-gcc
make[1]: Leaving directory '/home/myusername/SNAPCRAFT/lolcat-snap/c/parts/lolcat-c/build/musl'
Command '['/bin/sh', '/tmp/tmpetv6irll', 'make', '-j4']' returned non-zero exit status 2
Exit 1
$ _
Well, well. Finally an error!
So, the C version of lolcat was written using the musl libc library. This library was referenced as a git submodule, and snapcraft followed the instructions of the Makefile to pull and compile musl!
Then, for some reason, snapcraft fails to compile lolcat using a musl-gcc wrapper for this newly compiled musl libc. As if we need to specify that the make ; make install sequence should instead be make lolcat; make install. Indeed, looking at the instructions at https://github.com/jaseg/lolcat, this appears to be the case.
Therefore, how do we tell snapcraft that for the make plugin, it should run make lolcat instead of the standard make?
By reading the documentation of the Snapcraft make plugin, we find that
- make-parameters:
(list of strings)
Pass the given parameters to the make command.
Therefore, the parts: should look like
parts:
  lolcat-c:
    source: https://github.com/jaseg/lolcat.git
    plugin: make
make-parameters: [lolcat]
We enclose lolcat in brackets ([lolcat]) because make-parameters accepts a list of strings. If it accepted just a string, we would not need those brackets.
Let’s snap prime again!
$ snapcraft prime
Preparing to pull lolcat-c
[...]
Building lolcat-c
make lolcat -j4
"Using musl at musl"
[...]
chmod +x tools/musl-gcc
[...]
gcc -c -std=c11 -Wall -g -Imusl/include -o lolcat.o lolcat.c
[...]
Staging lolcat-c
Priming lolcat-c
$ ls prime/bin
ls: cannot access 'prime/bin': No such file or directory
Exit 2
$ ls prime/
censor*  command-lolcat-c.wrapper*  lolcat*  meta/  snap/
$ _
Success! The lolcat executable has been generated, and in fact it is located in prime/ (not in prime/bin/ as in all three previous cases). Also, it took 1 minute and 40 seconds to produce the executable on my computer!
Hmm, there is also a censor executable. I wonder, what does it do?
$ ls -l | ./censor
█▄█▄█ ██
█▄▄▄▄█▄▄█▄ █ ▄▄▄▄ ▄▄▄▄ █████ ███  ██ ██:██ ▄▄▄▄▄▄
█▄▄▄▄█▄▄█▄ █ ▄▄▄▄ ▄▄▄▄   ███ ███  ██ ██:██ ▄▄▄▄▄▄███▄█▄▄██▄.▄▄▄▄▄▄▄
█▄▄▄▄█▄▄█▄ █ ▄▄▄▄ ▄▄▄▄ █████ ███  ██ ██:██ █▄█▄▄█
█▄▄▄▄▄▄▄█▄ █ ▄▄▄▄ ▄▄▄▄  ████ ███  ██ ██:██ ▄▄█▄
█▄▄▄▄▄▄▄█▄ █ ▄▄▄▄ ▄▄▄▄  ████ ███  ██ ██:██ ▄▄▄▄
$ _
This censor executable is a filter, just like lolcat, and what it does is that it replaces any input letters with block characters. Like censoring the text. Let’s expose both lolcat and censor in this snap! Here is the apps: section,
apps:
  lolcat-c:
    command: lolcat
  censor:
    command: censor
For lolcat, since both the name: and the apps: command are named lolcat-c, the final executable will be lolcat-c. For censor, the executable will be named lolcat-c.censor (composed from the name: and the name we put in apps:).
Which confinement, strict or classic?
When we are about to publish a snap to the Ubuntu Store, we need to decide which confinement to apply, strict or classic.
The strict confinement will by default fully restrict the snap and it is up to us to specify what is allowed. For example, there will be no network connectivity, and we would need to explicitly specify it if we want to provide network connectivity.
The strict confinement can be tricky if the snap needs to read files in general. If the snap were to read file only from the user’s home directory, then that’s easy because we can specify plugs: [home] and be done with it.
In our case, lolcat can be used in two ways,
Note the different colors; the lolcat implementations start every time with a random initial rainbow color
In the first command, lolcat-go requires read access for the file /etc/lsb-release. This would be tricky to specify with the strict confinement, and we would need to use the classic confinement instead.
In the second command, lolcat-go is merely used as a filter. The executable is self-contained and does not read any files whatsoever. Because the cat command does the reading for lolcat.
Therefore, we can select here the strict confinement as long as we promise to use lolcat as a filter only. That is, lolcat would run fully confined! And it will fail if we ask it to read a file like in the first command.
Final configuration files
Here are the four final configuration files! I highlight below what really changes between them (bold+italics).
$ cat python/snap/snapcraft.yaml
name: lolcat-python
version: '0.44'
summary: lolcat utility written in Python
description: |
  lolcat-python is a utility similar to the Unix "cat" command.
  lolcat-python adds rainbow colors to the text output.
  The source code is available at https://github.com/tehmaze/lolcat

grade: stable
confinement: strict

apps:
  lolcat-python:
    command: lolcat

parts:
  lolcat-python:
    source: https://github.com/tehmaze/lolcat.git
    source-tag: '0.44'
    plugin: python

$ cat go/snap/snapcraft.yaml
name: lolcat-go
version: '20170226'
summary: lolcat utility written in golang
description: |
  lolcat-go is a utility similar to the Unix "cat" command.
  lolcat-go adds rainbow colors to the text output.
  The source code is available at https://github.com/cezarsa/glolcat

grade: devel
confinement: strict

apps:
  lolcat-go:
    command: glolcat.git

parts:
  lolcat-go:
    source: https://github.com/cezarsa/glolcat.git
    plugin: go

$ cat rust/snap/snapcraft.yaml
name: lolcat-rust
version: '20170226'
summary: lolcat utility written in Rust
description: |
  lolcat-rust is a utility similar to the Unix "cat" command.
  lolcat-rust adds rainbow colors to the text output.
  The source code is available at https://github.com/ur0/lolcat

grade: stable
confinement: strict

apps:
  lolcat-rust:
    command: lolcat

parts:
  lolcat-rust:
    source: https://github.com/ur0/lolcat.git
    plugin: rust

$ cat c/snap/snapcraft.yaml
name: lolcat-c
version: '20170226'
summary: lolcat utility written in C
description: |
  lolcat-c is a utility similar to the Unix "cat" command.
  lolcat-c adds rainbow colors to the text output.
  The source code is available at https://github.com/jaseg/lolcat

grade: stable
confinement: strict

apps:
  lolcat-c:
    command: lolcat
  censor:
    command: censor

parts:
  lolcat-c:
    source: https://github.com/jaseg/lolcat.git
    plugin: make
    make-parameters: [lolcat]
$ _
Quality testing
We have four lolcat snaps available to upload to the Ubuntu Store. Let’s test them first to see which ones are actually good enough to make it today to the Ubuntu Store!
A potential problem with filters like lolcat, is that they may not know how to deal with some UTF-8-encoded strings. In the UTF-8 encoding, text in English like what you read now, is encoded just like ASCII. Problems may occur when you have text in other scripts, where each Unicode character would occupy more than one byte. For example, each character in “Γεια σου κόσμε” is encoded as two bytes in the UTF-8 encoding. Furthermore, there are characters that are stored in Plane 1 of Unicode (Emojis!) which require the maximum of four bytes to encode in UTF-8. Here is an example of emoji characters, “” (if they appear as empty boxes, you do not have the proper fonts installed.

What we are seeing here, is that the current implementations of lolcat for Python and Go do not work with non-ASCII encodings. At the moment, they can only colorize text in English.
On the other hand, the Rust and C implementations work fine on all Unicode characters!
There is another issue to watch for. Specifically,

The Unix ls command takes care to understand when you are redirecting the output, and if you do so, by default it does not colorize the output. This is a very useful default for ls because in most cases you want clean text files with no escape sequences for the color. To further our testing, let’s see how well the remaining two lolcat implementations deal with content that happen to already have escape sequences (for example, for color),

We generated a text file (cat-color.txt) with color escape sequences. The Rust implementation choked on them, while the C implementation worked fine!
We have a winner! The C implementation of lolcat will be published in the Ubuntu Store, in the stable channel (available to all). The Rust implementation will be published in the candidate channel (pending a fix when dealing with text that already has escape sequences), while the Python and Go implementations will be published in the edge channels. (Note: if the authors of these lolcat implementations are reading this, my aim here is to demonstrate the different channels. I plan to write a follow-up post on how to fix these issues in the source code and how to re-release all snaps to the stable channel.)
Let’s publish to the Ubuntu Store
The documentation page Publish your snap from snapcraft.io explains the details on publishing a snap on the Ubuntu Store.
In summary, when releasing a snap to the Ubuntu Store, you specify in which channel(s) you want it to be in:

stable channel, for publicly available snaps. These can be searched when running snap find, and will be installed when you run snap install.
candidate channel, for snaps that are very soon to be released to the stable channel. For this and the following channels, you need to specify explicitly the channel when you try to install. Otherwise, you will get the error that the snap is not found.
beta channel, for beta versions of snaps.
edge channel, for testing versions of snaps. This is the furthest away from stable.

If you release a snap in the stable channel, it implies that it will be shown in those below. Or, if you release a snap in the beta channel, it will appear as well in the channel below (edge).
Furthermore, when we were filling in the metadata of the snapcraft.yaml configuration files, there was a field called grade, with options for either stable or devel. If the grade has been specified as devel, then the snap can only be installed in either the beta or edge channels.
So, this is what we are going to do:

The C implementation, lolcat-c, will have grade: stable, and get published in the stable channel of the Ubuntu Store.
The Rust implementation, lolcat-rust, will have grade: devel, and get published in the beta channel of the Ubuntu Store.
The Go and Python implementations, lolcat-go and lolcat-python, will have the grade: devel and get published in the edge channel of the Ubuntu Store.

We have already ran snapcraft login, and logged in with our Ubuntu Single SignOn (SSO) account.

We successfully registered the names on the Ubuntu Store, and then we pushed the snap files. We note down the revision, which is Revision 1 for each one of them.
The snapcraft release command looks like
  snapcraft [options] release <snap-name> <revision> <channel>

The snapcraft release command instructs the Ubuntu Store to release the recently pushed .snap file into the specified channels.
How to install them
Here we install lolcat-c.

First we perform a search for lolcat. The snap lolcat-c is found. There is a feature in the snap find command, that if we were to search for lolcat-c, it would show results for both lolcat and c (shows irrelevant results).
We then run the snap info command to show the Ubuntu Store info for the snap lolcat-c.
Then, we install lolcat-c, by running snap install lolcat-c.
Finally, we run snap info again, and we can see more information since the snap has just been installed. In particular, we can see that there is the additional command lolcat-c.censor. Oh, and then snap is just 24kB in size.
Let’s install the Rust implementation!

The Rust implementation of lolcat can be found in the beta and edge channels. In order to install it, we need to specify the correct channel (here, either beta or edge). And that’s it!

The Go implementation of lolcat is in the edge channel. We install and test it successfully.

Finally, the Python implementation of lolcat, installed from the edge channel.
Hope you enjoyed the post!

1 day ago

Nathan Haines: UbuCon Summit Comes to Pasadena this Week! from Planet Ubuntu

Once again, UbuCon Summit will be hosted by the Southern California Linux Expo in Pasadena, California on March 2nd and 3rd. UbuCon Summit is two days that celebrate Ubuntu and the community, and this year has some excitement in store.

Thursday's keynote will feature Carl Richell, the CEO and founder of System 76, a premium source of Ubuntu desktop and laptop computers. Entitled "Acrylic, Aluminum, Thumb Screws, and Heavy Machinery at System 76," he will share how System 76 is reinventing what it means to be a computer manufacturer, and talk about how they are changing the relationship between users and their devices. Don't miss this fascinating peek behind the scenes of a computer manufacturer that focuses on Ubuntu, and keep your ears peeled because they are announcing new products during the keynote!

We also have community member Amber Graner who will share her inspiring advice on how to forge a path to success with her talk "You Don't Need Permission to Contribute to Your Own Destiny," and Elizabeth Joseph who will talk about her 10 years in the Xubuntu community.

Thursday will wrap up with our traditional open Ubuntu Q&A panel where you can ask us your burning questions about Ubuntu, and Friday will see a talk from Michael Hall, "Sponsored by Canonical" where he describes the relationship between Canonical and Ubuntu and how it's changed, and Sergio Schvezov will describe Ubuntu's next-generation packaging format in "From Source to Snaps." After a short break for lunch and the expo floor, we'll be back for four unconference sessions, where attendees will come together to discuss the Ubuntu topics that matter most to them.

Ubuntu will be at booth 605 during the Southern California Linux Expo's exhibition floor hours from Friday through Sunday. You'll be able to see the latest version of Ubuntu, see how it works with touchscreens, laptops, phones, and embedded devices, and get questions answered by both community and Canonical volunteers at the booth.

Come for UbuCon, stay for SCALE! This is a weekend not to be missed!

SCALE 15x, the 15th Annual Southern California Linux Expo, is the largest
community-run Linux/FOSS showcase event in North America. It will be held
from March 2-5 at the Pasadena Convention Center in Pasadena, California.
For more information on the expo, visit https://www.socallinuxexpo.org

1 day ago

Costales: Papirus & Folder Color from Planet Ubuntu

I was impressed several times these last years because of the Folder Color's community :)) Today I had a new mail with great news, Papirus icon theme supports Folder Color too |o/Papirus colors for your file browserHow to install Folder Color (remember that Folder Color is preinstalled in Ubuntu MATE, then, install only the theme) & Papirus:sudo add-apt-repository ppa:papirus/papirussudo apt-get updatesudo apt-get install papirus-icon-themesudo apt-get install folder-colorNow, choose Papirus as your icon theme:System SettingsAnd it's done! Now you can easily spotting a folder with the color.Right click on a folder for changing the colorEnjoy it!

1 day ago

Martin Pitt: systemd 233 about to be released, please help testing from Planet Ubuntu

systemd 233 is scheduled to be released next week, and there is only
a handful of small issues left.
As usual there are tons of improvements and fixes,
but the most intrusive one probably is another attempt to move from legacy cgroup v1
to a “hybrid” setup where the new unified (cgroup v2) hierarchy is mounted at
/sys/fs/cgroup/unified/ and the legacy one stays at /sys/fs/cgroup/ as
usual. This should provide an easier path for software like Docker or LXC to
migrate to the unified hiearchy, but even that hybrid mode broke some bits.

While systemd 233 will not make it into Debian stretch or Ubuntu zesty, as both
are in feature freeze, it will soon be available in Debian experimental, and in
the next Ubuntu release after 17.04 gets released. Thus now is another good
time to give this some thorough testing!

To help with this, please give the
PPA with builds from upstream master
a spin. In addition to the usual packages for Ubuntu 16.10 I also uploaded a
build for Ubuntu zesty, and a build for Debian stretch
(aka testing) which also works on Debian sid. You can use that URL as an apt source:

deb [trusted=yes] https://people.debian.org/~mpitt/tmp/systemd-master-20170225/ /

These packages pass our autopkgtests and I tested them manually too. LXC and
LXD work fine, docker.io/runc needs a fix
which I uploaded to Ubuntu zesty.
(It’s not yet available in Debian, sorry.)

Please file reports about regressions on GitHub,
but please also le me know about successes on my Google+ page
so that we can get some idea about how many people tested this.

Thank you, and happy booting!

3 days ago

Stuart Langridge: Let’s Encrypt and TSOHost from Planet Ubuntu

This site used Cloudflare, because SSL is hard and my host wanted to charge me money for a certificate. However, that host, TSOHost, have now integrated Let’s Encrypt, and you can turn it on with two clicks. So, especially given the recent Cloudflare bug… I did. Hooray. SSL for me, being done by my host. Now I’ll never have to go to Cloudflare and purge the cache ever again. Good work TSOHost.

3 days ago

Stuart Langridge: Fruit machine hacking from Planet Ubuntu

From a Wired article (warning: adblocker-blocker, in-browser popups) via LWN:

[T]he operatives use their phones to record about two dozen spins on a [slot machine] they aim to cheat. They upload that footage to a technical staff in St. Petersburg, who analyze the video and calculate the machine’s pattern based on what they know about the model’s pseudorandom number generator. Finally, the St. Petersburg team transmits a list of timing markers to a custom app on the operative’s phone; those markers cause the handset to vibrate roughly 0.25 seconds before the operative should press the spin button.
The timed spins are not always successful, but they result in far more payouts than a machine normally awards: Individual scammers typically win more than $10,000 per day.

From Scarne’s Complete Guide to Gambling, published 1974, on the “Rhythm Boys” scam from 1949:

During 1949 a couple of thousand rhythm players, most of whom were women, were beating the slots all over Nevada and various other sections of the country. Hundreds were barred from the slot rooms, and slander suits (which were later dropped) were filed by some of the barred players. My findings show that national slot machine revenue took a real nose dive, dropping, from the 1948 figure of $700 million to a rockbottom low of $200 million in 1949. The rhythm players beat the slots during 1949 for half a billion dollars.

How did the original mysterious stranger happen to come up with his bright idea? And who was he? I did some further detective work and discovered that he was an Idaho farmer who, during his spare time, had been helping a slot-mechanic friend repair out-of-order machines. He discovered that the three wheels in certain makes of machine made exactly the same number of revolutions when the handle was pulled. He studied the clock fan which controls the length of time the reels spin and found that on some machines the clock went dead from seven to eight seconds after the reels stopped spinning. He also memorized the position of each symbol on each reel. In actual play, since he knew the relative positions on the reel of all the symbols, he could deduce from the nine visible symbols he could see through the window just where all the others were. Then, by timing himself to pull the machine’s level at precisely the right instant and before the clock gear went dead, he found that he could manipulate the desired symbols onto the pay line. Most of the rhythm players who learned the system later could, as a rule, control only the cherry on the first reel, but even that was good enough to empty the payoff coin tube; it just took a little longer.

Everything old is new again. Including exploiting insufficiently-random random-number-generators to make money in Vegas.

3 days ago

Elizabeth K. Joseph: Moving on from the Ubuntu Weekly Newsletter from Planet Ubuntu

Somewhere around 2010 I started getting involved with the Ubuntu News Team. My early involvement was limited to the Ubuntu Fridge team, where I would help post announcements from various teams, including the Ubuntu Community Council that I was part of. With Amber Graner at the helm of the Ubuntu Weekly Newsletter (UWN) I focused my energy elsewhere since I knew how much work the UWN editor position was at the time.

At the end of 2010 Amber stepped down from the team to pursue other interests, and with no one to fill her giant shoes the team entered a five month period of no newsletters. Finally in June, after being contacted numerous times about the fate of the newsletter, I worked with Nathan Handler to revive it so we could release issue 220. Our first job was to do an analysis of the newsletter as a whole. What was valuable about the newsletter and what could we do away with to save time? What could we automate? We decided to make some changes to reduce the amount of manual work put into it.
To this end, we ceased to include monthly reports inline and started linking to rather than sharing inline the upcoming meeting and event details in the newsletter itself. There was also a considerable amount of automation done thanks to Nathan’s work on scripts. No more would we be generating any of the release formats by hand, they’d all be generated with a single command, ready to be cut and pasted. Release time every week went from over two hours to about 20 minutes in the hands of an experienced editor. Our next editor would have considerably less work than those who came before them. From then on I’d say I’ve been pretty heavily involved.

The 500th issue lands on February 27th, this is an exceptional milestone for the team and the Ubuntu community. It is deserving of celebration, and we’ve worked behind the scenes to arrange a contest and a simple way for folks to say “thanks” to the team. We’ve also reached out to a handful of major players in the community to tell us what they get from the newsletter.
With the landing of this issue, I will have been involved with over 280 issues over 8 years. Almost every week in that time (I did skip a couple weeks for my honeymoon!) I’ve worked to collect Ubuntu news from around the community and internet, prepare it for our team of summary writers, move content to the wiki for our editors, and spend time on Monday doing the release. Over these years I’ve worked with several great contributors to keep the team going, rewarding contributors with all the thanks I could muster and even a run of UWN stickers specifically made for contributors. I’ve met and worked with some great people during this time, and I’m incredibly proud of what we’ve accomplished over these years and the quality we’ve been able to maintain with article selection and timely releases.
But all good things must come to an end. Several months ago as I was working on finding the next step in my career with a new position, I realized how much my life and the world of open source had changed since I first started working on the newsletter. Today there are considerable demands on my time, and while I hung on to the newsletter, I realized that I was letting other exciting projects and volunteer opportunities pass me by. At the end of October I sent a private email to several of the key contributors letting them know I’d conclude my participation with issue 500. That didn’t quite happen, but I am looking to actively wind down my participation starting with this issue and hope that others in the community can pick up where I’m leaving off.

I’ll still be around the community, largely focusing my efforts on Xubuntu directly. Folks can reach out to me as they need help moving forward, but the awesome UWN team will need more contributors. Contributors collect news, write summaries and do editing, you can learn more about joining here. If you have questions about contributing, you can join #ubuntu-news on freenode and say hello or drop an email to our team mailing list (public archives).

3 days ago

Full Circle Magazine: Full Circle Magazine #118 from Planet Ubuntu

This month:
* Command & Conquer
* How-To : Python (Arduino), Keep Your Linux Trim, and Program For Ubuntu Touch
* Graphics : Inkscape & Kdenlive
* ChromeCult: CryptUP
* Linux Labs: Digital Video & Rclone
* Book Review: Wicked Cool Shell Scripts
* Ubuntu Games: Mad Max
plus: News, Q&A, and soooo much more.

Get it while it’s hot!
http://fullcirclemagazine.org/issue-118/

3 days ago

Lubuntu Blog: Lubuntu Zesty Zapus Beta 1 has been released! from Planet Ubuntu

Lubuntu Zesty Zapus Beta 1 (soon to be 17.04) has been released! We have a couple papercuts listed in the release notes, so please take a look. A big thanks to the whole Lubuntu team and contributors for helping pull this release together. You can grab the images from here: http://cdimage.ubuntu.com/lubuntu/releases/zesty/beta-1/

4 days ago

The Fridge: Zesty Zapus Beta 1 Released from Planet Ubuntu

The first beta of the Zesty Zapus (to become 17.04) has now been released!
This milestone features images for Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu GNOME, Ubuntu Kylin, Ubuntu Studio, and Xubuntu.
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.
Beta 1 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 Beta 1 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 Beta 1 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.
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 Beta 1 images can be downloaded from:

http://cdimage.ubuntu.com/kubuntu/releases/zesty/beta-1/

More information about Kubuntu 17.04 Beta 1 can be found here:

https://wiki.ubuntu.com/ZestyZapus/Beta1/Kubuntu

Lubuntu
Lubuntu is a flavor of Ubuntu based on LXDE and focused on providing a very lightweight distribution.
The Lubuntu 17.04 Beta 1 images can be downloaded from:

http://cdimage.ubuntu.com/lubuntu/releases/zesty/beta-1/

More information about Lubuntu 17.04 Beta 1 can be found here:

https://wiki.ubuntu.com/ZestyZapus/Beta1/Lubuntu

Ubuntu Budgie
Ubuntu Budgie is a flavor of Ubuntu featuring the Budgie desktop environment.
The Ubuntu Budgie 17.04 Beta 1 images can be downloaded from:

http://cdimage.ubuntu.com/ubuntu-budgie/releases/zesty/beta-1/

More information about Ubuntu Budgie 17.04 Beta 1 can be found here:

https://wiki.ubuntu.com/ZestyZapus/Beta1/UbuntuBudgie

Ubuntu GNOME
Ubuntu GNOME is a flavor of Ubuntu featuring the GNOME desktop environment.
The Ubuntu GNOME 17.04 Beta 1 images can be downloaded from:

http://cdimage.ubuntu.com/ubuntu-gnome/releases/zesty/beta-1/

More information about Ubuntu GNOME 17.04 Beta 1 can be found here:

https://wiki.ubuntu.com/ZestyZapus/Beta1/UbuntuGNOME

Ubuntu Kylin
Ubuntu Kylin is a flavor of Ubuntu that is more suitable for Chinese users.
The Ubuntu Kylin 17.04 Beta 1 images can be downloaded from:

http://cdimage.ubuntu.com/ubuntukylin/releases/zesty/beta-1/

More information about Ubuntu Kylin 17.04 Beta 1 can be found here:

https://wiki.ubuntu.com/ZestyZapus/Beta1/UbuntuKylin

Ubuntu Studio
Ubuntu Studio is a flavor of Ubuntu configured for multimedia production.
The Ubuntu Studio 17.04 Beta 1 images can be downloaded from:

http://cdimage.ubuntu.com/ubuntustudio/releases/zesty/beta-1/

More information about Ubuntu Studio 17.04 Beta 1 can be found here:

https://wiki.ubuntu.com/ZestyZapus/Beta1/UbuntuStudio

Xubuntu
Xubuntu is a flavor of Ubuntu based on the Xfce desktop environment.
The Xubuntu 17.04 Beta 1 images can be downloaded from:

http://cdimage.ubuntu.com/xubuntu/releases/zesty/beta-1/

More information about Xubuntu 17.04 Beta 1 can be found here:

http://wiki.xubuntu.org/releases/17.04/release-notes

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.

http://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce

A big thank you to the developers and testers for their efforts to pull together this Beta release!
Originally posted to the ubuntu-devel-announce mailing list on Fri Feb 24 00:34:19 UTC 2017 by Simon Quigley on behalf of the Ubuntu Release Team

4 days ago

Kubuntu General News: Kubuntu 17.04 Beta 1 released for testers from Planet Ubuntu

Today the Kubuntu team is happy to announce that Kubuntu Zesty Zapus (17.04) Beta 1 is released . With this Beta 1 pre-release, you can see and test what we are preparing for 17.04, which we will be releasing in April.
NOTE: This is Beta 1 Release. Kubuntu Beta Releases are NOT recommended for:
* Regular users who are not aware of pre-release issues
* Anyone who needs a stable system
* Anyone uncomfortable running a possibly frequently broken system
* Anyone in a production environment with data or work-flows that need to be reliable
Getting Kubuntu 17.04 Beta 1:
* Upgrade from 16.10: run `do-release-upgrade -d` from a command line.
* Download a bootable image (ISO) and put it onto a DVD or USB Drive : http://cdimage.ubuntu.com/kubuntu/releases/zesty/beta-1/
Release notes: https://wiki.ubuntu.com/ZestyZapus/Beta1/Kubuntu

4 days ago