LibreOffice wins Bossie Awards 2016

bos16-libreoffice-100683495-origEvery year, InfoWorld editors and contributors pick the top open source software for data centers, clouds, developers, big data analysts, and IT pros. LibreOffice has been selected amongst InfoWorld’s top picks in open source business applications, collaboration, and middleware.

According to Doug Dineley, InfoWorld’s Executive Editor: “Open source software projects continue to fuel an amazing boom in enterprise technology development. If you want to know what our applications, data centers, and clouds will look like in the years to come, check out the winners of InfoWorld’s Best of Open Source Awards”.

Opera’s Free VPN Takes On Internet Privacy Challenge


Opera earlier this week released a new version of its browser, Opera 40, which comes with a free virtual private network service built in. The official rollout follows five months of user experimentation with a beta version. The company evaluated beta users’ feedback and subsequently brought on additional servers, added options for global or private browsing, and created versions that would run on iOS and Android. The VPN creates a secure connection to one of Opera’s five servers around the world, letting users spoof their IP address.

openSUSE Leap 42.2 Linux Operating System Gets a Second Beta with KDE Plasma 5.8

Today, September 22, 2016, the openSUSE Project proudly announced the release and immediate availability for download of the second Beta development milestone towards the openSUSE Leap 42.2 operating system.

openSUSE Leap 42.2 Beta 2 comes with several interesting improvements and up-to-date software components, including the KDE Applications 16.08.0, KDE Frameworks 5.26.0, GStreamer 1.8.3, GTK+ 2.24.31, GTK+ 3.20.9, json-glib 1.2.2, Wireshark 2.2.0, and Xen 4.7.0_12.

Other than that, the openSUSE KDE team did a fantastic job of integrating the recently announced Beta release of the KDE Plasma 5.8 LTS desktop environment into openSUSE Leap 42.2 Beta 2 so you can get an early taste and see if there are any show stoppers that need to be addressed before the final version lands in mid-November.

“The quality of the distribution at this point looks quite good,” said Ludwig Nussel, Le… (read more)

Development Release: openSUSE 42.2 Beta 2

The openSUSE project has announced the availability of a new beta snapshot for the project’s upcoming openSUSE 42.2 “Leap” release. The new beta provides a preview of the Plasma 5.8 desktop environment along with an update to GTK, bringing the toolkit to version 3.20.9. “The release of openSUSE….

Rocket.chat, a new snap is landing on your Nextcloud box and beyond!

Ubuntu Core Store

Last week Nextcloud, Western Digital and Canonical launched the Nextcloud box, a simple box powered by a Raspberry Pi to easily build a private cloud storage service at home . With the Nextcloud box, you are already securely sharing files with your colleagues, friends, and/or family.
The team at Rocket.chat has been asking “Why not add a group chat so you can chat in real-time or leave messages for one another?”

We got in touch with the team to hear about their story!

Here’s Sing Li from Rocket.chat telling us about their journey to Ubuntu Core!

Introducing Rocket.chat

Rocket.chat is a slack-like server that you can run on your own servers or at home… and installing it with Ubuntu core couldn’t be easier. Your private chat server will be up and running in 2 minutes.

If you’ve not heard of them, Rocket.Chat is one of the largest MIT licenced open source group chat project on GitHub with over 200 global contributors, 9,000 stars, and 40,000 community servers deployed world-wide.

Rocket.chat is an optimized nodejs application, bundled in compressed tar zip. To install it a system admin would need to untar the optimized app, and install its dependency on the server . He/She would then need to configure the server via environment variables and be configured to survive restart using a service manager.. Combined with the typical routine of setting up and configuring a reverse proxy and getting DNS plus SSL set up correctly. This meant that system administrators had to spend on average 3 hours deploying the rocket.chat server before they can even start to see the first login page.

Being a mature production server, the configuration surface of Rocket.Chat is also very large. Currently we have over a hundred configurable settings for all sort of different use-cases. Getting configuration just right for a use-case adds to the already long time required to deploy the server.

Making installation a breeze

We started to look for alternatives that can ubiquitously delivery our server product to the largest possible body of end users (deployer of chat servers) and provide a non-complex, pleasant initial out-of-box experience. If it can help with updating of software and expediting installation of new version – it would be a bonus. If it can further reduce our complex build pipeline complexity, then it is a sure winner.

When we first saw snaps, we knew it had everything were looking for. The ubiquity of Ubuntu 16.04 LTS, Ubuntu 14.04 LTS, plus Ubuntu Core for IoT – means we can deliver Rocket.Chat to an incredibly large audience of server deployers globally – all via one single package. But also cater for the increasing number of users asking us to run a Rocket.chat server on a Raspberry Pi.

With Snap, we only have one bundle for all the Linux platforms supported. It is right here in the snap store What’s real cool is that even the formerly manually built ARM based server, for Raspberry Pi and other IoT devices, can also be part of the same snap. It enjoys the same simplicity of installation, and transactional update just like other Intel 64 bit Linux platforms.

Our next step will be to distribute our desktop client with snaps. We have a vision that once we tag a release, within seconds a build process is kicked off through the CI and published to the snap store.

The asymmetric nature of the snap delivery pipeline has definite benefits. By paying the cost of heavy processing work up front during the build phase, snap deployment is lightning fast. On most modern Intel servers or VPSes, `snap install rocketchat.server` takes only about 30 seconds. The server is ready to handle hundreds of users immediately, available at URL `http://<server address>:3000`.

Consistent with the snap design philosophy, we have done substantial engineering to come up with a default set of ready-to-go configuration settings that supports the most common use cases of a simple chat server.

What this enables us to do is to deliver a 30s “instantly gratifying” experience to system admistator who’d like to give Rocket.Chat server a try – with no obligation whatsover. Try it, if you like it, keep it and learn.

All of the complexity of configuring a full-fledged production server is folded away. The system administrator can learn more about configuration and customization at her/his own pace later.

Distributing updates in a flash

We work on new features on a develop branch (Github), and many of our community members test on this branch with us. Once the features are deemed stable, they are merged down to master (Github) where our official releases (Github) reside. Both branches are rigged to Continuous Integration via travis. Our travis script optimizes, compresses and bundle the distributions and then pushes them out to the various distribution channels that we support, many of them requires further special sub-builds and repackaging that can take substantial time.

Some distributions even calls for manual build every release. For example, we build manually for ARM architecture (Github), to support a growing community of Raspberry Pi makers, hobbyists, and IoT enthusiasts at Github

In addition to the server builds, we also have our desktop client(Github). Every new release requires a manual build on Windows, OSX, and Ubuntu. This build process requires a member of our team to physically login to a Windows(x86 and x86_64) OSX and Ubuntu(x86 and x86_64) machine to create our releases. Once this release was built, our users then had to goto our release page to manually download the Ubuntu release and install it.

That’s where snap also bring a greatt a much simpler distribution mechanism and a better user experience. When we add features and push new, every one of our users will be enjoying it within a few hours- automatically. The version update is transactional, so if they can always roll back to the previous version if they’d like.

In fact, we make use of the stable and edge channels corresponding to our master and develop branches. Community members helping us to test the latest software is on the edge channel , and often gets multiple updates throughout the day as we fix bugs and add new features.

We look forward to the point where our desktop client is also available as a snap and when our users no longer have to wrestle with updating their Desktop Clients. Like the server we are able to deliver their updates quickly and seamlessly.

Android Banking Trojan First to Gain Root Privileges

Developers behind an Android banking Trojan have fortified the malware with an exploit to help it gain root privileges; this is the first time a mobile banker that tries to obtain root privileges has been seen in the wild. Researchers detected the Tordow Trojan in February, but attackers have apparently tweaked it over the last several months in order to help it gain root privileges.
Once malicious code in the app is triggered, it downloads additional malware, including an exploit pack that’s downloaded to the system folder which grants the attacker root privileges on the device. With that, the attacker can do pretty much whatever he wants, Kivva writes. The Trojan can steal credentials from browsers installed on infected devices, either the default Android browser or Chrome, if it’s installed, and eavesdrop on SMS messages and calls. By being able to access browser information, attackers can glean bank account information from victims, such as logins, stored banking passwords, and cookies, assuming they’ve been saved in the browser.

Source: https://threatpost.com/android-banking-trojan-first-to-gain-root-privileges/120707/
Submitted by: Arnfried Walbrecht

Monitoring “big software” stacks with the Elastic Stack

Big​ ​Software​ ​is​ ​a​ ​new​ ​class​ ​of​ ​application.​ ​It’s​ ​composed​ ​of​ ​so​ ​many moving​ ​pieces​ ​that​ ​humans,​ ​by​ ​themselves,​ ​cannot​ ​design,​ ​deploy​ ​or operate​ ​them.​ ​OpenStack,​ ​Hadoop​ ​and​ ​container-based​ ​architectures​ ​are all​ ​examples​ ​of​ ​​Big​ ​Software​.

  • Gathering​ ​service​ ​metrics​ ​for​ ​complex​ ​big​ ​software​ ​stacks​ ​can​ ​be​ ​a​ ​chore
  • Especially​ ​when​ ​you​ ​need​ ​to​ ​warehouse,​ ​visualize,​ ​and​ ​share​ ​the​ ​metrics
  • It’s​ ​not​ ​just​ ​about​ ​measuring​ ​machine​ ​performance,​ ​but​ ​application performance​ ​as​ ​well

You​ ​usually​ ​need​ ​to​ ​warehouse​ ​months​ ​of​ ​history​ ​of​ ​these​ ​metrics​ ​so​ ​you can​ ​spot​ ​trends.​ ​This​ ​enables​ ​you​ ​to​ ​make​ ​educated​ ​infrastructure decisions.​ ​That’s​ ​a​ ​powerful​ ​tool​ ​that’s​ ​usually​ ​offered​ ​on​ ​the​ ​provider level.​ ​But​ ​what​ ​if​ ​you​ ​run​ ​a​ ​hybrid​ ​cloud​ ​deployment?​ ​Not​ ​every​ ​cloud service​ ​is​ ​created​ ​equally.

The​ ​Elastic​ ​folks​ ​provide​ ​everything​ ​we​ ​need​ ​to​ ​make​ ​this​ ​possible.

Additionally​ ​we​ ​can​ ​connect​ ​it​ ​to​ ​​all​ ​sorts​​ ​of​ ​other​ ​bundles​ ​in​ ​the​ ​charm.

Stack

Big Software is a new class of application. It’s composed of so many moving pieces that humans, by themselves, cannot design, deploy or operate them. OpenStack, Hadoop and container-based architectures are all examples of Big Software.

Gathering service metrics for complex big software stacks can be a chore. Especially when you need to warehouse, visualize, and share the metrics. It’s not just about measuring machine performance, but application performance as well.

You usually need to warehouse months of history of these metrics so you can spot trends. This enables you to make educated infrastructure decisions. That’s a powerful tool that’s usually offered on the provider level. But what if you run a hybrid cloud deployment? Not every cloud service is created equally.

The Elastic folks provide everything we need to make this possible. Additionally we can connect it to all sorts of other bundles in the charm store. We can now collect data on any cluster, store it, and visualize it. Let’s look at the pieces that are modeled in this bundle:

  • Elasticsearch – a distributed RESTful search engine
  • Beats – lightweight processes that gather metrics on nodes and ship them to Elasticsearch.
    • Filebeat ships logs
    • Topbeat ships “top-like” data
    • Packetbeat provides network protocol monitoring
  • Dockerbeat is a community beat that provides app container monitoring
  • Logstash – Performs data transformations, and routing to storage. As an example: Elasticsearch for instant visualization or HDFS for long term storage and analytics
  • Kibana – a web front end to visualize and analyze the gathered metrics

Getting Started

First, install and configure Juju. This will allow us to model our clusters easily and repeatedly. We used LXD as a backend in order to maximize our ability to explore the cluster on our desktops/laptops. Though you can easily deploy these onto any major public cloud.

juju deploy ~containers/bundle/beats-core

This will give you a complete stack, it looks like this:

 

Note: if you wish to deploy the latest version of this bundle, the ~containers team is publishing a development channel release as new beats are added to the core bundle.

juju deploy ~containers/bundle/beats-core --channel=development

Once everything is deployed we need to deploy the dashboards:

juju action do kibana/0 deploy-dashboard dashboard=beats

Now do a `juju status kibana` to get the ip address to the unit it’s allocated. Now we are… monitoring nothing. We need something to connect it to, and then introduce it to beats, so something like:

juju deploy myapplication juju add-relation filebeat:beats-host myapplication juju add-relation topbeat:beats-host myapplication

Let’s connect it to something interesting, like an Apache Spark deployment.

Integrating with other bundles

The standalone bundle is useful but let’s use a more practical example. The Juju Ecosystem team has added elastic stack monitoring to a bunch of existing bundles. You don’t even have to manually connect the beats-core deployment to anything, you can just use an all in one bundle:

 

To deploy this bundle in the command line:

juju deploy apache-processing-spark

We also recommend running `juju status` periodically to check the progress of the deployment. You can also just open up a new terminal and keep `watch juju status` in a window so you can have the status continuously display while you continue on.

In this bundle: Filebeat and Topbeat act as subordinate charms. Which means they are co-located on the spark units. This allows us to use these beats to track each spark node. And since we’re adding this relationship at the service level; any subsequent spark nodes you add will automatically include the beats monitors. The horizontal scaling of our cluster is now observable.

Let’s get the kibana dashboard ready:

juju set-config kibana dashboards="beats"

Notice that this time, we used charm config instead of an action to deploy the dashboard. This allows us to blanket configure, and deploy the kibana dashboards from a bundle. Reducing the number of steps a user must take to get started.

After deployment you will need to do a `juju status kibana` to get the IP address of the unit. Then browse to it in your web browser. For those of you deploying on public clouds: you will need to also do `juju expose kibana` to open a port in the firewall to allow access. Remember, to make things accessible to others in our clouds Juju expects you to explicitly tell it to do this. Out-of-the-box we keep things closed.
When you get to the kibana GUI you need add `topbeat-*` or `filebeat-*` in the initial screen setup to set up Kibana’s index. Make sure you click the “Create” button for each one:

Create

Now we need to load the dashboard’s we’ve included for you, click on the “Dashboard” section and click the load icon, then select the “topbeat-dashboard”:

topbeat dashboard

near-realtime

Now you should see a your shiny new dashboard:

Shiny dashboard

You now have an observable Spark cluster! Now that your graphs are up, let’s run something to ensure all the working pieces are working, let’s do a quick pagerank benchmark:

juju run-action spark/0 pagerank

This will output a UUID for your job for you to query for results:

juju show-action-output 

You can find more about available actions in the bundle’s documentation. Feel free to launch the action multiple times if you want to exercise the hardware, or run your own Spark jobs as you see fit.

By default the `apache-processing-spark` bundle gives us three nodes. I left those running for a while and then decided to grow the cluster. Let’s add 10 nodes

juju add-unit -n10 spark

Your `juju status` should be lighting up now with the new units being fired up, and in Kibana itself we can see the rest of the cluster coming online in near-realtime:

near-realtime

Here you can see the CPU and memory consumption of the cluster. You can see the initial three nodes hanging around, and then as the other nodes come up, beats gets installed and they report in, automatically.

Why automatically? ‘apache-processing-spark’ technically is just some yaml. The magic is that we are not just deploying code, we’re modelling the relationship between these applications:

relations: - [spark, zookeeper] - ["kibana:rest", "elasticsearch:client"] - ["filebeat:elasticsearch", "elasticsearch:client"] - ["filebeat:beats-host", "spark:juju-info"] - ["topbeat:elasticsearch", "elasticsearch:client"] - ["topbeat:beats-host", "spark:juju-info"]

So when spark is added, you’re not just adding a new machine, you’re mutating the scale of the application within the model. But what does that mean?

A good way to think about it is just like simple elements and compounds. For example: Carbon Monoxide (CO) and Carbon Dioxide (CO2) are built from the exact same elements. But the combination of those elements allow for two different compounds with different characteristics. If you think of your infrastructure similarly, you’re not just designing the components that compose it. But the number of interactions that those components have with themselves and others.

So, automatically deploying filebeat and topbeat when spark is scaled just becomes an automatic part of the lifecycle. In this case, one new spark unit results in one new unit of filebeat, and one new unit of topbeat. Similarly, we can change this model as our requirements change.

This post-deployment mutability of infrastructure is one of Juju’s key unique features. You’re not just defining how applications talk and relate to each other. You’re also defining the ratios of units to their supporting applications like metrics collection.

We’ve given you two basic elements of beats today, filebeat, and topbeat. And like chemistry, more elements make for more interesting things. So now let’s show you how to expand your metrics-gathering to another level.

Charming up your own custom beat

Elastic has engineered Beats to be expandable. They have invested effort in making it easy for you to write your own “beat”. As you can imagine, this can lead to an explosion of community-generated beats for measuring all sorts of things. We wanted to enable any enthusiast of the beats community to be able to hook into a Juju deployed workload.

As part of this work we’ve published a beats base layer. This will allow you to generate a charm for your custom beat. Or any of the community written beats for that matter. Then deploy it right into your model, just like we do with topbeat and filebeat. Let’s look at an example:

The Beats-base layer

Beats Base provides some helper python code to handle the common patterns every beats unit will undergo. Such as declaring to the model how it will talk to Logstash and/or Elasticsearch. This is always handled the same way among all the beats. So we’re keeping developers from needing to repeat themselves.

Additionally the elasticbeats library handles:

  • Unit index creation
  • Template rendering in any context
  • Enabling the beat as a system service

So starting from beats-base, we have 3 concerns to address and we will have delivered our beat:

  • How to install your beat (delivery)
  • How to configure your beat (template config)
  • Declare your beats index (payload delivery from installation step)

Let’s start with Packetbeat as an example. Packetbeat is an open source project that is designed to provide real‑time analytics for web, database, and other network protocols.

charm create packetbeat

Every charm starts with a layer.yaml

includes:

  • beats-base
  • apt
  • repository: http://github.com/juju-solutions/layer-packetbeat

Let’s add a little bit of metadata.yaml

name: packetbeat summary: Deploys packetbeat maintainer: Charles Butler  description: | data shipper that integrates with Elasticsearch to provide real-time analytics for web, database, and other network protocols series: - trusty Tags: monitoring analytics networking

With those meta files in place we’re ready to write our reactive code.

reactive/packetbeat.py

For delivery of packetbeat, elastic has provided a deb repository for the official beats. This makes delivery a bit simpler using the apt-layer. The consuming code is very simple:

import charms.apt @when_not('apt.installed.packetbeat') def install_filebeat(): status_set('maintenance', 'Installing packetbeat') charms.apt.queue_install(['packetbeat'])

This completes our need to deliver the application. The apt-layer will handle all the usual software delivery things for us like installing and configuring an apt repository, etc. Since this layer is reused in charms all across the community, we merely reuse it here.

The next step is modeling how we react to our data-sources being connected. This typically requires rendering a yaml file to configure the beat, starting the beat daemon, and reacting to the beats-base beat.render state.

In order to do this we’ll be adding:

  • Configuration options to our charm
  • A Jinja template to render the yaml configuration
  • Reactive code to handle the state change and events

The configuration for packetbeat comes in the form of declaring protocol and port. This makes attaching packetbeat to anything transmitting data on the wire simple to model with configuration. We’ll provide some sane defaults, and allow the admin to configure the device to listen on.

Config.yaml device: type: string default: any description: Device to listen on, eg eth0 protocols: type: string description: | the ports on which Packetbeat can find each protocol. space separated protocol:port format. default: "http:80 http:8080 dns:53 mysql:3306 pgsql:5432 redis:6379 thrift:9090 mongodb:27017 memcached:11211" templates/packetbeat.yml # This file is controlled by Juju. Hand edits will not persist! interfaces: device: {{ device }} protocols: {% for protocol in protocols -%} {{ protocol }}: ports: {{ protocols[protocol] }} {% endfor %} {% if elasticsearch -%} output: elasticsearch: hosts: {{ elasticsearch }} {% endif -%} {% if principal_unit %} shipper: name: {{ principal_unit }} {% endif %} reactive/packetbeat.py from charms.reactive import set_state from charmhelpers.core.host import service_restart from charmhelpers.core.hookenv import status_set from elasticbeats import render_without_context @when('beat.render') @when_any('elasticsearch.available', 'logstash.available') def render_filebeat_template(): render_without_context('packetbeat.yml', '/etc/packetbeat/packetbeat.yml') remove_state('beat.render') service_restart('packetbeat') status_set('active', 'Packetbeat ready')

With all these pieces of the charm plugged in, run a `charm build` in your layer directory and you’re ready to deploy the packetbeat charm.

juju deploy cs:bundles/beats-core juju deploy cs:trusty/consul juju deploy ./builds/packetbeat juju add-relation packetbeat elasticsearch juju add-relation packetbeat consul

Consul is a great test, we can attach a single beat and monitor DNS, and Web traffic thanks to its UI

juju set-config packetbeat protocols=”dns:53 http:8500”

single beat and monitor DNS

Load up the kibana dashboard, and look under the “Discover” tab. There will be a packetbeat index, and data aggregating underneath it. Units requesting cluster DNS will start to pile on as well.

To test both of these metrics, browse around the Consul UI on port 8500. Additionally you can ssh into a unit, and dig @ the consul dns server to see DNS metrics populate.

Populating the Packetbeat dashboard from here is a game of painting with data by the numbers.

Conclusion

Observability is a great feature to have in your deployments. Whether it’s a brand new 12-factor application or the simplest of MVC apps. Being able to see inside the box is always a good feature for modern infrastructure to own.

This is why we’re excited about the Elastic stack! We can plug this into just about anything and immediately start gathering data. We’re looking forward to seeing how people bring in new beats to connect other metrics to existing bundles.

We’ve included this bundle in our Swarm, Kubernetes and big data bundles out of the box. I encourage everyone who is publishing bundles in the charm store to consider plugging in this bundle for production-grade observability.

Double XP Weekend Top Tips

Less than a day to go before Double XP kicks off. Make sure you’re prepared!

MATE 1.16 Desktop Environment Officially Released with More GTK+ 3 Improvements

Just a few minutes ago, Ubuntu MATE project leader, and now a Canonical employee, Martin Wimpress, informed us about the availability of the MATE 1.16 desktop environment for GNU/Linux operating systems.

It has been six long months since the MATE 1.14 desktop environment was announced, during which the MATE development team worked hard on bringing lots of improvements to the core applications included in the lightweight graphical desktop interface used by default in the Ubuntu MATE operating system and other GNU/Linux distributions, as well as lots of other enhancements and cosmetic changes.

“After 6 months of development the MATE Desktop team are proud to announce the release of MATE Desktop 1.16. We’d like to thank every MATE contributor for their help making this release possible,” says Martin Wimpress. “The release is focused on improving GTK3+ compatibility, migrating components to newer libraries, fixing bugs and code hygene.”

Here’s what’s new in MA… (read more)

GNOME 3.22 Released

gnome3-18

The GNOME Community has just announced the official release of GNOME 3.22.  GNOME 3.22 — which is slated to be used as the desktop environment for Fedora Workstation 25 — provides a multitude of new features, including a the updated Files application, and comprehensive Flatpak integration with the Software application.

Fedora users that want to try out the new features in GNOME 3.22 can install a pre-release version of Fedora 25, which currently contains a pre-release of GNOME 3.22, but will be updated to include the stable 3.22 release. Alternatively, if you are running Fedora 24, and want to try out individual applications from the GNOME 3.22 release, these can be installed via Flatpak.

Files Application (nautilus)

One of the major applications in the GNOME family that got updates for the 3.22 release was the Files application (nautilus). As previously reported here on the Fedora Magazine, Files has a nifty new batch file renaming ability now baked in.

Batch File renaming in GNOME 3.22

Batch File renaming in GNOME 3.22

Another neat new feature in Files is updated sorting and view options controls, allowing you to switch between the grid and list view with a single click, and simplification of the zoom and sorting options. These changes were implemented after a round of usability testing by Outreachy intern Gina Dobrescu.

Updated Sorting controls in the Files application

Updated Sorting controls in the Files application

Software Application

software

GNOME Software 3.22

The Software application in 3.22 is also updated, with the landing page showing more application tiles. Star ratings — that were introduced in a previous release are now more prominently displayed, and new colour coded badges indicate if an application is Free Software. Installation of Flatpak applications from Flatpak repositories is now also supported in the Software application.

Keyboard Settings

The keyboard settings in 3.22 are also updated, providing easier ways to search, browse and configure your keyboard settings and shortcuts

Keyboard Settings in GNOME 3.22

Keyboard Settings in GNOME 3.22

More Information

For more information on what makes up the 3.22 release, check out the official release announcement, and the release notes.

 

Ubuntu 16.10 (Yakkety Yak) Final Beta Freeze Now in Effect, Lands September 22

Today, September 21, 2016, Canonical’s Adam Conrad announced that the soon-to-be-released Ubuntu 16.10 (Yakkety Yak) Final Beta is now in freeze stage and will arrive, as initially planned, on September 22, 2016.

However, early adopters should look for the release late Thursday or very early on Friday, September 23, because the Ubuntu developers are a little busy right now pushing last minute updates to the stable archive, and they also managed to land the new Linux 4.8 kernel packages earlier today, as reported right here on Softpedia.

“Due to a rocky start on this beta with landing a last-minute kernel and a few other hiccups, it’s possible the actual release will happen on Friday morning instead of Thursday night, but let’s … (read more)

Flatpak 0.6.11 Linux Universal Binary Format Released with New Features, Fixes

Alex Larsson from the Flatpak project, the universal binary format that aims to simplify application distribution across multiple GNU/Linux operating systems, announced the release of Flatpak 0.6.11.

Flatpak 0.6.11 is a small maintenance version that comes approximately one week after the release of the previous one, Flatpak 0.6.10, bringing a new FLATPAK_CHECK_VERSION macro in the libflatpak library to automatically check the installed Flatpak version, a new option to the flatpak-builder command, namely “–show-deps,” to allow listing of all the files on which the manifest depends.

The list of changes continues with support for using dashes in application IDs, but app developers are being informed by Alex Larsson that to make them work with symboli… (read more)

Snapcraft GUI 3.0 Released for Ubuntu 16.04 LTS (Xenial Xerus) and Ubuntu 16.10

Softpedia was informed today, September 21, 2016, by Snapcraft GUI developer Keshav Bhatt about the release of a new major update, version 3.0, for Ubuntu 16.04 LTS and above.

Last week, we introduced you guys to the Snapcraft GUI application, whose main goal is to help application developers who want to distribute their projects across multiple GNU/Linux distributions using Canonical’s innovative Snap universal binary package format build Snappy packages more easily.

So, yes, Snapcraft GUI is a graphical user interface to the Snapcraft command-line tool for creating Snap packages, and the latest release, Snapcraft GUI 3.0, is here to implement a “Recent Project” functionality, as well as a Project Notes feature that lets you write and save notes for your Snapcraft projects.

Additionally, there’s now a “Donation”… (read more)

GTK+ 3.22 GUI Toolkit Released for GNOME 3.22 as Devs Prepare for GTK+ 4.0

Immediately after announcing the final release of the GNOME 3.22 desktop environment, Matthias Clasen also had the pleasure of informing us about the availability of the GTK+ 3.22 GUI toolkit.

Most of you out there developing GTK+ apps know what this open source software is all about, and the latest stable build is now 3.22, released as part of the GNOME 3.22 desktop environment. However, it looks like this will be the last release in the GTK+ 3 series, as the developers are now preparing to bump the development builds to version 3.90.x towards GTK+ 4.0.

“The 3.22 release is the last development release in the GTK+ 3. series. GTK+ 3.22 will be maintained as the long-term stable version of GTK+ 3, and new development will move to the GTK+ 3.90.x releases. To learn more about the GTK+ roadmap, read: read more)

Ubuntu to Run Much Faster in Virtual Machines, as Well as When Using It Remotely

After releasing the OTA-13 update for Ubuntu Phone and Ubuntu Tablet devices, Canonical is now working hard on putting all the pieces together for next month’s Ubuntu 16.10 (Yakkety Yak) operating system.

Ubuntu 16.10 will be officially released on October 13, 2016, but until then we will be able to get an early taste of its new features by downloading the Final Beta ISO images, which for some of the opt-in flavors is called Beta 2. However, for Ubuntu itself, this will be the first and only Beta release.

We’ve already told you that Ubuntu 16.10 (Yakkety Yak) is now officially powered by Linux kernel 4.8, as well as that it already received some of the packages from the recently released read more)

Wayland 1.12 Next-Gen Linux Display Server Officially Released with Many Goodies

Today, September 21, 2016, Bryce Harrington has had the great pleasure of announcing the immediate availability of the Wayland 1.12.0 display server for GNU/Linux operating systems, along with the Weston 1.12.0 compositor.

Development for Wayland 1.12 and Weston 1.12 started exactly a month ago when the first Alpha build was seeded to public testers, and it already contained many of the new functionalities and improvements implemented in this final build we can install today on our GNU/Linux distributions.

Since then, several other development builds have been released for testing, but no other major features were added, only small bug fixes. Therefore, we believe that many of you monitoring the Wayland/Weston development builds may be aware that it comes with a new wl_display_add_protocol logger API.

“A new wl_display_add_protocol logger API provides a new, interactive way to debug requests; along with this are new APIs for examining clients and their resources. … (read more)

APT 1.3 Linux Package Manager Has Been Officially Released in Debian Unstable

On September 20, 2016, the APT development team, through Julian Andres Klode, announced the release of version 1.3 of the APT (Advanced Packaging Tool) command-line package manager.

APT 1.3 has been in the works since early May this year, and it received a total of twelve development releases that brought numerous improvements and new features to one of the oldest and most acclaimed package managers for Debian-based GNU/Linux distributions, such as Ubuntu and Linux Mint.

And the biggest ones worth mentioning here are support for multiple fingerprints in the Signed-By feature making package distribution more secure, along with Signed-By support in “Release” files in the form of HTTP Public Key Pinning (HPKP), as well as the ability to use the same redirection mirror for all index files.

Multiple improvements were added to the EDSP (External Dependency Solver Protocol) protocol specificati… (read more)

Ubuntu 16.10 (Yakkety Yak) Is Now Officially Powered by Linux Kernel 4.8

Ubuntu 16.10 being in development and all that, it usually gets at least a few updated packages every 24 hours, and today, September 21, 2016, we were surprised to see that the Linux 4.8 kernel packages have finally landed.

The fact of the matter is that the Ubuntu developers have been working on rebasing the Linux kernel of Ubuntu 16.10 (Yakkety Yak) on the upcoming Linux 4.8 kernel series, which is currently in development too, and the final release is expected to hit the streets later this month or on October 2, 2016.

Until today, Ubuntu 16.10 shipped with the long-term supported Linux 4.4 kernel from the Ubuntu 16.04 LTS (Xenial Xerus) operating system, but patched with some of the goodies from the now deprecated Linux 4.6 kernel series. The Ubuntu devs briefly attempted to rebase Yakkety’s kernel on the Linux 4.7 branch too.

However, considering the fact that they set in stone that the final release of Ubuntu 16.10 (Yakkety Yak) will be powered by Linux kerne… (read more)

A new look for Drupal.org

As you can see we’ve put a fresh coat of paint on Drupal.org – but the changes run below the surface. This latest iteration of the front page brings the key concepts of our design system to the forefront: Clean, Modern, Technical.

Preview of the new home page design

This change also brings new editorial tools for Drupal.org content editors. The new home page provides us more flexibility with content and presentation, and so you’ll see more frequent updates, more information about DrupalCon, and more editorial flexibility on the home page than you’ve seen in the past. These tools are also helping us to build cleaner, modern landing pages – like you’ve just seen with our Fall Membership Campaign.

We’ve previewed this work with several key members of the community and the board, and we want to say thank you to everyone who’s given us their feedback on this first step for our new home page. We also want to give an extra special thank you to dyannenova for her contributions to this effort.

This is just the beginning – very soon we’ll have a new visual look for the case studies that are featured on the home page, and then shortly after that we’ll begin promoting solutions to Drupal evaluators in specific industries, like Higher Education, Media & Publishing, and Government.

If Drupal.org is the home of the community, than the front page is our front door. We want to welcome new users and evaluators of Drupal, highlight the project’s strengths, and promote news and happenings from throughout the ecosystem.

We hope you like the changes, and we think you’ll like the upcoming iterations even more. We’d love to hear your feedback!

Leostream Joins Canonical’s Charm partner programme

Leostream Corporation, a leading developer of hosted desktop connection management software, has joined the Charm partner programme to facilitate the deployment of virtual desktops on Ubuntu OpenStack. The partner program helps solution providers make best use of Canonical’s model driven operations system, Juju; enabling instant workload deployment, integration, and scaling on any public or private cloud, as well as bare metal with just a click of a button. The Juju Charm Store has a rapidly growing number of charms available to DevOps teams, with hundreds of cloud-based applications available.

“OpenStack has long been a solution for controlling large pools of compute, storage, and networking resources and has recently turned heads as a solution for virtual desktop infrastructure (VDI),” comments Karen Gondoly CEO of Leostream. “As the world’s most popular operating system for OpenStack, Ubuntu provides a reliable way to build out a manageable cloud.  By making the Leostream Connection Broker available from Canonical’s Charm store, DevOps teams have a fast path to delivering desktops and remote sessions in a cloud-based environment.”

A pioneer in the evolving desktop virtualization space, Leostream will be “charming” its flagship connection broker software, which has quickly become an essential tool for enterprise-grade OpenStack VDI.  Coined the “ultimate connection broker” and the “one broker to rule them all”, the software provides a single management console to integrate a variety of systems and platforms including physical and virtual infrastructures, Windows and Linux Operating Systems, and any number of high-performance display protocols.

To overcome the technical barriers of building and managing OpenStack VDI, Leostream configuration and setup is included in the Canonical BootStack solution. BootStack is an end-to-end service that includes the design, implementation, and ongoing management of an OpenStack cloud on Ubuntu. Combined with Leostream, organizations can get up and running with hosted desktops faster, easier, and in a more cost-predictable way.

“Together, Leostream and Canonical simplify the deployment and migration of virtual desktop workloads into an OpenStack cloud, eliminating legacy, expensive VDI stacks and providing cloud-based, on-demand desktops to users across an organization,” says Stefan Johansson, Global Software Alliances Director, Canonical’s Cloud Division. “We are excited to welcome Leostream to our catalogue to accelerate the adoption of OpenStack VDI.”

The Leostream Connection Broker will be available directly from the Charm store in the fall of 2016. In the meantime, the latest version of the connection broker is available for download from the: Leostream website. For more information on Canonical’s Charm Partner Programme, go to http://partners.ubuntu.com/programmes/charm.