You are here

Planet Ubuntu

Subscribe to Feed Planet Ubuntu
Planet Ubuntu - http://planet.ubuntu.com/
Përditësimi: 4 orë 40 min më parë

The Fridge: Ubuntu Weekly Newsletter Issue 614

Hën, 20/01/2020 - 11:40md

Welcome to the Ubuntu Weekly Newsletter, Issue 614 for the week of January 12 – 18, 2020. The full version of this issue is available here.

In this issue we cover:

The Ubuntu Weekly Newsletter is brought to you by:

  • Krytarik
  • Bashing-om
  • Chris Guiver
  • Wild Man
  • 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, this issue of the Ubuntu Weekly Newsletter is licensed under a Creative Commons Attribution ShareAlike 3.0 License

Stuart Langridge: Number word sequences

Dje, 19/01/2020 - 11:02md

I was idly musing about number sequences, and the Lychrel algorithm. If you don’t know about this, there’s a good Numberphile video on it: basically, take any number, reverse it, add the two, and if you get a palindrome stop, and if you don’t, keep doing it. So start with, say, 57, reverse to get 75, add them to get 57+75=132, which isn’t a palindrome, so do it again; reverse 132 to get 231, add to get 132+231=363, and that’s a palindrome, so stop. There are a bunch of interesting questions that can be asked about this process (which James Grime goes into in the video), among which are: does this always terminate? What’s the longest chain before termination? And so on. 196 famously hasn’t terminated so far and it’s been tried for several billion iterations.

Anyway, I was thinking about another such iterative process. Take a number, express it in words, then add up the values of all the letters in the words, and do it again. So 1 becomes ONE, and ONE is 15, 14, 5 (O is the fifteenth letter of the alphabet, N the fourteenth, and so on), so we add 15+14+5 to get 34, which becomes THIRTY FOUR, and so on. (We skip spaces and dashes; just the letters.)

Take a complete example: let’s start with 4.

  • 4 -> FOUR -> 6+15+21+18 = 60
  • 60 -> SIXTY -> 19+9+24+20+25 = 97
  • 97 -> NINETY-SEVEN -> 14+9+14+5+20+25+19+5+22+5+14 = 152
  • 152 -> ONE HUNDRED AND FIFTY-TWO -> 15+14+5+8+21+14+4+18+5+4+1+14+4+6+9+6+20+25+20+23+15 = 251
  • 251 -> TWO HUNDRED AND FIFTY-ONE -> 20+23+15+8+21+14+4+18+5+4+1+14+4+6+9+6+20+25+15+14+5 = 251

and 251 is a fixed point: it becomes itself. So we stop there, because we’re now in an infinite loop.

Do all numbers eventually go into a loop? Do all numbers go into the same loop — that is, do they all end up at 251?

It’s hard to tell. (Well, it’s hard to tell for me. Some of you may see some easy way to prove this, in which case do let me know.) Me being me, I wrote a little Python programme to test this out (helped immeasurably by the Python 3 num2words library). As I discovered before, if you’re trying to pick out patterns in a big graph of numbers which all link to one another, it’s a lot easier to have graphviz draw you pretty pictures, so that’s what I did.

I’ve run numbers up to 5000 or so (after that I got a bit bored waiting for answers; it’s not recreational mathematics if I have to wait around, it’s a job for which I’m not getting paid). And it looks like numbers settle out into a tiny island which ends up at 251, a little island which ends up at 285, and a massive island which ends up at 259, all of which become themselves1. (You can see an image of the first 500 numbers and how they end up; extending that up to 5000 just makes the islands larger, it doesn’t create new islands… and the diagrams either get rather unwieldy or they get really big and they’re hard to display.2)

I have a theory that (a) yes all numbers end up in a fixed point and (b) there probably aren’t any more fixed points. Warning: dubious mathematical assertions lie ahead.

There can’t be that many numbers that encode to themselves. This is both because I’ve run it up to 5000 and there aren’t, and because it just seems kinda unlikely and coincidental. So, we assume that the fixed points we have are most or all of the fixed points available. Now, every number has to end up somewhere; the process can’t just keep going forever. So, if you keep generating numbers, you’re pretty likely at some point to hit a number you’ve already hit, which ends up at one of the fixed points. And finally, the numbers-to-words process doesn’t grow as fast as actual numbers do. Once you’ve got over a certain limit, you’ll pretty much always end up generating a number smaller than oneself in the next iteration. The reason I think this is that adding more to numbers doesn’t make their word lengths all that much longer. Take, for example, the longest number (in words) up to 100,000, which is (among others) 73,373, or seventy-three thousand, three hundred and seventy-three. This is 47 characters long. Even if they were all Z, which they aren’t, it’d generate 47×26=1222, which is way less than 73,373. And adding lots more doesn’t help much: if we add a million to that number, we put one million on the front of it, which is only another 10 characters, or a maximum added value of 260. There’s no actual ceiling — numbers in words still grow without limit as the number itself grows — but it doesn’t grow anywhere near as fast as the number itself does. So the numbers generally get smaller as they iterate, until they get down below four hundred or so… and all of those numbers terminate in one of the three fixed points already outlined. So I think that all numbers will terminate thus.

The obvious flaw with this argument is that it ought to apply to the reverse-and-add process above too and it doesn’t for 196 (and some others). So it’s possible that my approach will also make a Lychrel-ish number that may not terminate, but I don’t think it will; the argument above seems compelling.

You might be thinking: bloody English imperialist! What about les nombres, eh? Or die Zahlen? Did you check those? Mais oui, I checked (nice one num2words for supporting a zillion languages!) Same thing. There are different fixed points (French has one big island until 177, a very small island to 232, a 258, 436 pair, and 222 which encodes to itself and nothing else encodes to it, for example.Not quite: see the update at the end. Nothing changes about the maths, though. Images of French and German are available, and you can of course use the Python 3 script to make your own; run it as python3 numwords.py no for Norwegian, etc.) You may also be thinking “what about American English, eh? 101 is ONE HUNDRED ONE, not ONE HUNDRED AND ONE.” I have not tested this, partially because I think the above argument should still hold for it, partially because num2words doesn’t support it, and partially because that’s what you get for throwing a bunch of perfectly good tea into the ocean, but I don’t think it’d be hard to verify if someone wants to try it.

No earth-shattering revelations here, not that it matters anyway because I’m 43 and you can only win a Fields Medal if you’re under forty, but this was a fun little diversion.

Update: Minirop pointed out on Twitter that my code wasn’t correctly highlighting the “end” of a chain, which indeed it was not. I’ve poked the code, and the diagrams, to do this better; it’s apparent that both French and German have most numbers end up in a fairy large loop, rather than at one specific number. I don’t think this alters my argument for why this is likely to happen for all numbers (because a loop of numbers which all encode to one another is about as rare as a single number which encodes to itself, I’d guess), but maybe I haven’t thought about it enough!

  1. Well, 285 is part of a 285, 267, 313, 248, 284, 285 loop.
  2. This is also why the graphs use neato, which is much less pleasing a layout for this than the “tree”-style layout of dot, because the dot images end up being 32,767 pixels across and all is a disaster.

Podcast Ubuntu Portugal: Assiste ao vivo ao próximo episódio do Podcast Ubuntu Portugal

Dje, 19/01/2020 - 5:54md

Com o objectivo constante de inovar vamos hoje, dia em que gravamos o episódio 74 do nosso podcast preferido, permitir a todos os que lerem esta publicação a tempo – e tiverem disponibilidade – poder assistir à gravação do PUP.

No futuro, este será um privilégio da patronagem (é $1, deixem-se de coisas!) mas por enquanto todos vão poder fazer parte.

Queremos com esta iniciativa atingir 3 objectivos:

  • Dar mais amor aos nossos patronos;
  • Aumentar o número de seguidores que temos no yt;
  • Aumentar o número de patronos.

Se, nesta altura, continuas com vontade de assistir, basta abrires esta ligação uns minutos antes das 22.00:
https://www.youtube.com/watch?v=OBer6DroddY

Stuart Langridge: The tiniest of Python templating engines

Dje, 19/01/2020 - 11:30pd

In someone else’s project (which they’ll doubtless tell you about themselves when it’s done) I needed a tiny Python templating engine. That is: I wanted to be able to say, here is a template string, please substitute a bunch of variables into it. Now, Python already does this, in about thirty different ways, and str.format or string.Template do most of it as built-in.

str.format works like this:

"My name is {name} and I am {age} years old".format(name="Stuart", age=43)

and string.Template like this:

t=string.Template( "My name is $name and I am $age years old" ).safe_substitute(name="Stuart", age=43)

Both of which are pretty OK.

However, what they’re missing is loops; having more than one of a thing in your template, and looping over a list, substituting it each time. Every even fractionally-more-featureful templating system has this, whether Mustache or Jinja or whatever, of course, but I didn’t want another dependency. All I needed was str.format but with loops. So, I thought, I’ll write one, in about four lines of code, so I can just drop the function in to my Python file and then I’m good.

def LoopTemplate(s, ctx): def loophandler(m): md = m.groupdict() return "".join([LoopTemplate(md["content"], val) for val in ctx[md["var"]]]) return re.sub(r"\{loop (?P<var>[^}]+)\}(?P<content>.*?)\{endloop\}", loophandler, s, flags=re.DOTALL).format(**ctx)

And lo, twas so. So I can now do

LoopTemplate( "I am {name} and my imps' names are: {loop imps}{name}{endloop}", { "name": "Stuart", "imps": [ {"name": "Pyweazle"}, {"name": "Grimthacket"}, {"name": "Hardebon"} ] } )

and it all works. Not revolutionary, of course, but I was mildly pleased with myself.

Much internal debate about whether loophandler() should have been a lambda, but I eventually decided it was more confusing that way, on the grounds that it was confusing me and I knew what it was meant to be doing.

A brief explanation: re.sub lets you pass a function as the thing to replace with, rather than just a string. So we find all examples of {loop something}...{endloop} in the passed string, look up something in the “context”, or the dict of substitution variables you passed to LoopTemplate, and then we call LoopTemplate again, once per item in something (which is expected to be a list), and pass it the ... as its string and the next item in something as its context. So it all works. Of course, there’s no error handling or anything — if something isn’t present in the context, or if it’s not a list, or if you stray in any other way from the path of righteousness, it’ll incomprehensibly blow up. So don’t do that.

Ubuntu Blog: Design and Web team summary – 17 January 2020

Pre, 17/01/2020 - 4:57md

The second iteration of this year is the last one before our mid-cycle sprint next week.

Here’s a short summary of the work the squads in the Web & Design team completed in the last 2-week iteration.

Web, Ubuntu and Brand squad

Web is the squad that develop and maintain most of the brochure websites across Canonical and is the team that underpins our toolsets and architure of our projects. They maintain the CI and deployment of all websites we maintain. The Brand Squad are tasked with updating and managing the overall style of Canonical, Ubuntu and the many fantastic products we create both on and off-line.

New canonical.com website

Yesterday we released the new canonical.com website, which has been a few months in the making. The site is more succinct, consolidating the content into a single page, with clear, standout statements:

The largest piece of work was the new careers section, which provides a more interactive experience for discovering careers at Canonical:

Redesign of /download/server/thank-you

We’ve updated the thank-you page for downloading Ubuntu Server with a new form for signing up to our newsletter and also getting access to the CLI pro-tips 2020 cheatsheet.

451 Research: Kubernetes report

We’ve highlighted a new report from 451 Research on our homepage and with a dedicated page of its own.

MAAS

The MAAS squad develops the UI for the maas project.

The maas-ui team was focused on two main areas this iteration – fixing up UI bugs for the upcoming 2.7 release and completing the first part of the work on importing the main machine listing data into the React machine listing component. In addition to that we spent a significant amount of time preparing for the upcoming sprint in South Africa, ensuring we have all the specifications documents we need to discuss with engineers and have prepared a presentation to inform everyone of the work we’ve done so far this cycle.

JAAS

The JAAS squad develops the UI for the Charm Store and Juju GUI projects.

Controller view

The team worked on a first iteration of the Controller view for the new JAAS dashboard. This view is tailored for admin in particular, listing all the controllers that are under that group or user.

‘Group by’ functionality

The team implemented the functionality of grouping the model list table of the JAAS dashboard by status (default), owner and clouds and regions.

User testing

During our product sprint in South Africa we will be doing some user testing of the JAAS dashboard with internal users, before expanding the target group to customers and community users. The results will help us understand the prioritisation of the implementation and possible feature requests.

CharmHub POC

The Snapcraft team implemented the design of the detail page of the new CharmHub store exploring different front-end solutions in order to optimise the maintenance of the current Snap store on Snapcraft.io and the new CharmHub.io

UX and design explorations

The team explored different solutions on the graphs for the controller view of the JAAS dashboard, the side navigation and the table react component working with the MAAS team on the definition of the patterns.

Vanilla

The Vanilla squad design and maintain the design system and Vanilla framework library. They ensure a consistent style throughout web assets.

Multistage builds for docs.vanillaframework.io

We’ve been working on optimising our production builds recently. One of these optimisation is to use Docker’s build kit and multistage builds to both reduce image size and speed up subsequent builds.

This iteration we applied these enhancements to the build for docs.vanillaframework.io to improve the site’s release process.

Styling of the range input

Our existing Slider component was simply a styling on the HTML range input, so to keep consistency with the rest of native form inputs we removed the necessity of using p-slider class name. Any range input will now get Vanilla styling automatically.

This change will be live with the next version of Vanilla framework.

Encapsulating components

To make sure all of our components can be included and built independently from each other we started the work on encapsulating component styles, building them individually and making sure we have example pages for each individual component stylesheet.

This will allow us to make sure we don’t introduce any unnecessary dependencies between patterns in the future.

Snapcraft

The Snapcraft team work closely with the snap store team to develop and maintain the snap store website.

Integrating automated builds into snapcraft.io

We want to gradually import functionality from build.snapcraft.io to snapcraft.io. We have added authentication with GitHub and allowed the publisher the possibility of linking a GitHub repository with a Snap, this is done through a call to the Launchpad API.

Ubuntu Blog: 5 key steps to take your IoT device to market

Pre, 17/01/2020 - 4:50md

IoT businesses are notoriously difficult to get off the ground. No matter how good your product is or how good your team is, some of the biggest problems you will face are just in getting to market and maintaining your devices once they’re in the field. The webinar will take a look at how Canonical’s Brand Store product allows you to get to market while catering for long term problems and the need to keep your product up to date in the future.

More specifically, this webinar will look at the common problems we see organisations facing on their way to getting an IoT device to market, and cover five key steps to solve these problems. Along the way we will dig a little into serval case studies Canonical has done with various customers and partners to show you what has already been achieved with these solutions.

Watch the webinar

Kubuntu General News: Plasma 5.18 LTS Beta (5.17.90) Available for Testing

Pre, 17/01/2020 - 10:48pd

Are you using Kubuntu 19.10 Eoan Ermine, our current Stable release? Or are you already running our development builds of the upcoming 20.04 LTS Focal Fossa?

We currently have Plasma 5.17.90 (Plasma 5.18 Beta)  available in our Beta PPA for Kubuntu 19.10.

The 5.18 beta is also available in the main Ubuntu archive for the 20.04 development release, and can be found on our daily ISO images.

This is a Beta Plasma release, so testers should be aware that bugs and issues may exist.

If you are prepared to test, then…..

For 19.10 add the PPA and then upgrade

sudo add-apt-repository ppa:kubuntu-ppa/beta && sudo apt update && sudo apt full-upgrade -y

Then reboot. If you cannot reboot from the application launcher,

systemctl reboot

from the terminal.

In case of issues, testers should be prepare to use ppa-purge to remove the PPA and revert/downgrade packages.

Kubuntu is part of the KDE community, so this testing will benefit both Kubuntu as well as upstream KDE Plasma software, which is used by many other distributions too.

  • If you believe you might have found a packaging bug, you can use a launchpad.net to post testing feedback to the Kubuntu team as a bug, or give feedback on IRC [1], Telegram [2] or mailing lists [3].
  • If you believe you have found a bug in the underlying software, then bugs.kde.org is the best place to file your bug report.

Please review the release announcement and changelog.

[Test Case]

* General tests:
– Does plasma desktop start as normal with no apparent regressions over 5.16 or 5.17?
– General workflow – testers should carry out their normal tasks, using the plasma features they normally do, and test common subsystems such as audio, settings changes, compositing, desktop affects, suspend etc.

* Specific tests:
– Check the changelog:
– Identify items with front/user facing changes capable of specific testing. e.g. “clock combobox instead of tri-state checkbox for 12/24 hour display.”
– Test the ‘fixed’ functionality or ‘new’ feature.

Testing involves some technical set up to do, so while you do not need to be a highly advanced K/Ubuntu user, some proficiently in apt-based package management is advisable.

Testing is very important to the quality of the software Ubuntu and Kubuntu developers package and release.

We need your help to get this important beta release in shape for Kubuntu and the KDE community as a whole.

Thanks!

Please stop by the Kubuntu-devel IRC channel or Telegram group if you need clarification of any of the steps to follow.

[1] – irc://irc.freenode.net/kubuntu-devel
[2] – https://t.me/kubuntu_support
[3] – https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel

Podcast Ubuntu Portugal: Ep 73 – WSL por Nuno do Carmo (parte 1)

Enj, 16/01/2020 - 11:45md

Episódio 73 – WSL por Nuno do Carmo (parte 1). 2 Ubuntus e 1 Windows entram num bar e… Isto podia ser o início de mais uma anedota, mas o que realmente aconteceu foi mais 2 Ubuntus e 1 Windows entram num podcast e começam a falar sem parar sobre WSL, e não só, de tal maneira que a ocnversa ficou a meio e terá de ser cotinuada no próximo episódio. Já sabem: oiçam, comentem e partilhem!

  • https://meta.wikimedia.org/wiki/WikiCon_Portugal
  • https://www.humblebundle.com/books/python-machine-learning-packt-books?partner=PUP
  • https://www.humblebundle.com/books/holiday-by-makecation-family-projects-books?partner=PUP
  • https://stackoverflow.com/questions/56979849/dbeaver-ssh-tunnel-invalid-private-key
  • https://fosdem.org
  • https://github.com/PixelsCamp/talks
  • https://pixels.camp/
Apoios

Este episódio foi produzido e editado por Alexandre Carrapiço (Thunderclaws Studios – captação, produção, edição, mistura e masterização de som) contacto: thunderclawstudiosPT–arroba–gmail.com.

Podem apoiar o podcast usando os links de afiliados do Humble Bundle, porque ao usarem esses links para fazer uma compra, uma parte do valor que pagam reverte a favor do Podcast Ubuntu Portugal.
E podem obter tudo isso com 15 dólares ou diferentes partes dependendo de pagarem 1, ou 8.
Achamos que isto vale bem mais do que 15 dólares, pelo que se puderem paguem mais um pouco mais visto que têm a opção de pagar o quanto quiserem.

Se estiverem interessados em outros bundles não listados nas notas usem o link https://www.humblebundle.com/?partner=PUP e vão estar também a apoiar-nos.

Atribuição e licenças

A música do genérico é: “Won’t see it comin’ (Feat Aequality & N’sorte d’autruche)”, por Alpha Hydrae e está licenciada nos termos da [CC0 1.0 Universal License](https://creativecommons.org/publicdomain/zero/1.0/).

Este episódio e a imagem utilizada estão licenciados nos termos da licença: Attribution-NonCommercial-NoDerivatives 4.0 International (CC BY-NC-ND 4.0), cujo texto integral pode ser lido aqui. Estamos abertos a licenciar para permitir outros tipos de utilização, contactem-nos para validação e autorização.

Jonathan Riddell: KUserFeedback 0.9.90 Beta Release

Mër, 15/01/2020 - 5:15md

KUserFeedback is a framework for collecting user feedback for applications via telemetry and surveys.

The library comes with an accompanying control and result UI tool.

https://download.kde.org/unstable/kuserfeedback/

Signed by Jonathan Riddell <jr@jriddell.org> 2D1D5B0588357787DE9EE225EC94D18F7F05997E

KUserFeedback as it will be used in Plasma 5.18 LTS

Dmitry Shachnev: Qt packages built with OpenGL ES support are now available

Mër, 15/01/2020 - 3:55md

Some time ago, there was a thread on debian-devel where we discussed how to make Qt packages work on hardware that supports OpenGL ES, but not the desktop OpenGL.

My first proposal was to switch to OpenGL ES by default on ARM64, as that is the main affected architecture. After a lengthy discussion, it was decided to ship two versions of Qt packages instead, to support more (OpenGL variant, architecture) configurations.

So now I am announcing that we finally have the versions of Qt GUI and Qt Quick libraries that are built against OpenGL ES, and the release team helped us to rebuild the archive for compatibility with them. These packages are not co-installable together with the regular (desktop OpenGL) Qt packages, as they provide the same set of shared libraries. So most packages now have an alternative dependency like libqt5gui5 (>= 5.x) | libqt5gui5-gles (>= 5.x). Packages get such a dependency automatically if they are using ${shlibs:Depends}.

These Qt packages will be mostly needed by ARM64 users, however they may be also useful on other architectures too. Note that armel and armhf are not affected, because there Qt was built against OpenGL ES from the very beginning. So far there are no plans to make two versions of Qt on these architectures, however we are open to bug reports.

To try that on your system (running Bullseye or Sid), just run this command:

# apt install libqt5gui5-gles libqt5quick5-gles

The other Qt submodule packages do not need a second variant, because they do not use any OpenGL API directly. Most of the Qt applications are installable with these packages. At the moment, Plasma is not installable because plasma-desktop FTBFS, but that will be fixed sooner or later.

One major missing thing is PyQt5. It is linking against some Qt helper functions that only exist for desktop OpenGL build, so we will probably need to build a special version of PyQt5 for OpenGL ES.

If you want to use any OpenGL ES specific API in your package, build it against qtbase5-gles-dev package instead of qtbase5-dev. There is no qtdeclarative5-gles-dev so far, however if you need it, please let us know.

In case you have any questions, please feel free to file a bug against one of the new packages, or contact us at the pkg-kde-talk mailing list.

Ubuntu Blog: New Ubuntu Theme in Development for 20.04

Mar, 14/01/2020 - 10:00md

Yaru is the user interface theme that has been used in Ubuntu since 18.10. The theme is what determines the colours, borders, shadows, size, and shape of individual elements on the screen.

Last week, the Yaru team visited London to plan the future of Yaru with members of Canonical’s Design and Ubuntu Desktop teams. I’d like to thank Carlo, Frederik, Mads and Stuart for travelling across Europe to collaborate with us at the Canonical offices.

Yaru in Ubuntu 19.10 The face of Ubuntu Desktop

Since Ubuntu 18.10, Yaru has been the face of Ubuntu Desktop; the most popular Linux based desktop operating system. Changing the Ubuntu Desktop default theme requires careful consideration and the work created by the Yaru team isn’t just limited to Ubuntu.

Yaru is available for Fedora users and for Arch users, too. Last October, Pop! OS rebased their theme on Yaru. We’ve also had requests for Yaru variants that use the colours of Linux Mint, Manjaro and the Ubuntu flavours.

The importance of branding

For most operating system vendors, having a distinctive look for the OS is important in establishing their brand. For example, one of the most obvious visual changes planned for Ubuntu 20.04 LTS is that check-boxes, radio buttons, and switches will change from green to Ubuntu aubergine. This will reduce the abundance of colours used overall, while still making it unmistakably Ubuntu.

Yaru before and after the design sprint.

Through our attendance at conferences such as GUADEC and Linux Application Summit, we’ve learned that some GNOME/GTK contributors develop using distributions other than Ubuntu. However, they want to ensure their applications render correctly for Ubuntu users without having to dual boot or maintain Ubuntu virtual machines. To help facilitate that, a community-contributed FlatPak of the Yaru theme will be made available to compliment the packages of Yaru already available in the Fedora archive and the Arch Linux AUR.

To further minimise the likelihood of inconsistent application presentation when using Yaru, the Yaru team more closely aligned with the upstream Adwaita theme last year. With the introduction of GitHub actions, the Yaru team are now automatically receiving each upstream Adwaita change as a pull request on the Yaru repo. This helps reduce the delta between the themes and enables the Yaru developers to stay current.

Light, dark, and in between

Ten years ago, Ubuntu 10.04 LTS — with its Radiance and Ambiance themes — popularised the choice of having lighter and darker variations of the same default theme.

The original theme for GNOME 3.0, Adwaita, was designed with the intent that there would be one theme with no variations. Since then, however, macOS and Windows have adopted a similar approach to Ubuntu, with light and dark choices.

With Ubuntu 20.04 LTS, we plan to go one step further. As well as the dark variation, and the standard version with light controls and dark headers, we will be introducing a third variation that is light throughout. We also plan to reintroduce the ability to switch between these variations within ‘Settings’, for which we have design work in progress.

Yaru vairant switcher mockup

In future, we would also like these settings to switch the theme for shell elements, such as the top bar and notification bubbles. Achieving this without requiring a logout each time will require additional work in GNOME Shell – something we are investigating.

Folder icon exploration

We are experimenting with some alternative folder icons that aim to preserve the Ubuntu identity, while maintaining good contrast in both the light and dark variants of Yaru.

Easier contribution

We have also planned some activities to make it easier for potential new contributors to get involved with the Yaru project. This includes better documentation that describes the theme architecture, making the build system support alternative coloured variants which we will pre-populate with an alternative theme for each of the official Ubuntu flavours.

The Yaru team has also been regularly attending GNOME Design team meetings. Members of the Canonical Design and Desktop team will also join those meetings on a regular basis so we can better collaborate with upstream.

Not finished yet

In between mugs of tea on the roof of the Canonical offices in London, we achieved a great deal during the design sprint. But, we’re not finished yet and have identified a number of areas for improvement we’ll be working on in the weeks ahead. I hope you’ve enjoyed this little look at what we’re working towards for Ubuntu 20.04.

Ubuntu Blog: Kubernetes: a secure, flexible and automated edge for IoT developers

Mar, 14/01/2020 - 5:48md

Cloud native software such as containers and Kubernetes and IoT/edge are playing a prominent role in the digital transformation of enterprise organisations. They are particularly critical to DevOps teams that are focused on faster software releases and more efficient IT operations through collaboration and automation. Most cloud native software is open source which broadens the developer pool contributing and customising the software. This has led to streamlined versions of Kubernetes with low footprints which are suited for IoT/edge workloads.

Read this report from analyst firm, 451 Research, to learn more including:

  • How the maturity of IoT and the value it brings is underpinned by the right technology stack
  • The factors driving execution venues for IoT workloads
  • The requirements needed to maximise usage of Kubernetes at the edge

To view the report, fill out the form below.

Jonathan Riddell: Zanshin 0.5.71

Mar, 14/01/2020 - 4:37md

https://zanshin.kde.org/2020/01/14/zanshin-0.5.71/

We are happy and proud to announce the immediate availability of Zanshin 0.5.71.

This updates the code to work with current libraries and apps from Kontact.

The GPG signing key for the tar is
Jonathan Riddell with 0xEC94D18F7F05997E
download.kde.org