22 Apr 2019

feedPlanet Ubuntu

The Fridge: Ubuntu Weekly Newsletter Issue 575

Welcome to the Ubuntu Weekly Newsletter, Issue 575 for the week of April 14 - 20, 2019. The full version of this issue is available here.

In this issue we cover:

The Ubuntu Weekly Newsletter is brought to you by:

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

22 Apr 2019 10:23pm GMT

Ubuntu Studio: Ubuntu Studio at Linux Fest Northwest 2019

Council Chair Erich Eickmeyer will be in Bellingham, WA, USA this weekend for Linux Fest Northwest 2019, and will be bringing his audio setup to demonstrate Ubuntu Studio at the Ubuntu table. Check out the post on his personal blog!

22 Apr 2019 5:49pm GMT

Erich Eickmeyer: Gearing Up for Linux Fest Northwest 2019!

This next weekend (April 26-28th, 2019) I will be in Bellingham at Bellingham Technical College for Linux Fest Northwest to help at the Ubuntu table!

I will be demonstrating Ubuntu Studio and my audio setup.

I also have a few giveaways for fans of Ubuntu Studio fans. After all, nearly everybody loves vinyl stickers.

I even put a couple of them on my pickup truck! (The Tux sticker is from HelloTux, where you can pick up some amazing Ubuntu Studio clothing!)

I look forward to seeing you there! Also attending (that I know of) will be Valorie Zimmerman (Kubuntu), Dustin Krysak (Ubuntu Budgie), Simon Quigley (Lubuntu), Martin Wimpress (Ubuntu MATE, Canonical), and Alan Pope (Canonical). It's going to be a blast!

22 Apr 2019 5:45pm GMT

Jono Bacon: Open Source Won’t Save A Subpar Product

Bonus points for those of you who can guess where the main image for this post is from.

One of the interesting elements of working with a range of different companies is being able to better understand the dynamics that influence how well a community will succeed or fail. These dynamics are many and broad, and include having a solid strategy, the right balance of transparency, executive and frontline and support, simple and sensible tooling, and more. Sadly, the availability of gin plays no concrete role in this success. Bah humbug.

Within the context of companies building a community around a product, one of the most critical influences of this success, frankly, is having a product that (a) people actually want, and (b) that they can wrap their heads around it.

This may seem obvious, but it is more complex than it may seem. If you look at the rich tapestry of open source, you have some very popular projects that serve broad needs such as Kubernetes, Node.js, Git, Docker, Angular, and others. But then, you have projects that serve very niche needs such as OpenMRS, SymPy, Astropy, and eht-imaging. All of these projects are thriving open source communities.

Now, for some companies watching these projects growing in adoption and market recognition, it can generate a seemingly logical conclusion:

"Surely if we open source our struggling project on GitHub or GitLab we will attract an audience of users and developers, and therefore help our broader market success, right?"

Well, Danger, Will Robinson.

A Balanced View

While there is little doubt that open source can have a heck of an impact on projects, products, and companies, the way in which you accomplish this impact needs to pull together four key components:

  1. Product - firstly, you need to have a product that the market wants, that can add value for your target audience, and maps well to your chosen open source model.
  2. Product/Engineering Workflow - secondly, if you are going to run a public open source project, you need to ensure your product and engineering teams can operate with an open, asynchronous workflow and can interface with public contributors.
  3. Community Strategy - thirdly, you are going to need a clear, unambiguous strategy for how you structure your community, hire the right team members, target the right audiences, build growth, and more.
  4. Internal Capabilities - finally, you are going to need to develop the skills in your company to accomplish all of the above. This will require staff training, support, mentoring, and leadership.

Now, often when I am brought into a company, the client is typically very interested in focusing on points 2 - 4. After all, this is what a lot of people associate with the work I do.

My first questions though almost always focus on (1). Is the product you have suitable for open sourcing, and will open sourcing it bring you and your prospective community the value you and they want?

Open source is not a panacea. It is not a solution that will revive an uninteresting or poorly built product. I never recommend anyone goes down the open source road until they have assessed this important product suitability consideration first. Otherwise, they risk doing a lot of work for very limited benefit for anyone.

Essential Questions To Ask

Here's the deal: open source requires a careful balance of open workflow, community/contributor management, and a clear delineation of where the lines are drawn between your open source and non-open source projects (and which teams work on what.)

To put it rather glibly, open source is not as simple as chucking some code into a public repository and blogging about it. It requires a careful balance of internal and public workflow, and needs a significant investment of time and energy to do well. As such, you want to be sure that this time and energy is not just worth it, but has a realistic chance of success for both you and your community.

When you are considering this, I recommend asking yourself 4 key questions:

#1. Is there a market need/fit for your product?

Open source has become increasingly interesting to companies who want to get developers using their product or platform. Developers are increasingly influential decision-makers in modern tech firms, and often prefer open source platforms.

Put the open source element to one side though and ask yourself the objective question, "Does your project serve a clear need and deliver enough value for your target audience?"

Market fit? Would you wear this while on the phone so to not disturb others? No, you are not insane.
Credit.

The #1 thing your audience are looking for is clear, valuable functionality. Does the software do something that pragmatically make your audience's lives better? If it doesn't deliver this, no amount of open source will save it.

So, try to understand what your core audience want and ensure your project can deliver it. If this is a new project, publish a roadmap for these key target features and focus on staffing the delivery of them. A compelling 1.0 is essential to interest both users and potential contributors.

#2. What is the on-boarding experience like for new users?

On a related note, how easy is it to get started using your project? Can a new user get up and running and experience tangible value within 10 minutes? No? Then you you need optimize your on-boarding experience.

I have seen some bloody horror stories here: projects that make users jump through endless hoops, require complicated configuration (with little to no documentation), have dependencies on obscure or unavailable services, and other dents in the experience.

This is the model I have developed over the years for thinking about building a clear onramp:

Every step should logically lead to the next step. If it doesn't, your onramp needs fixing.

Your audience should be able to proceed simply and logically from one step to the next ultimately getting to the star, which is a piece of tangible value for them (e.g. completing a task, solving a problem, etc.).

Now, while every project will use a slightly different set of steps, an onramp generally breaks down into understanding value, setting up tools, learning skills, and using the tools and skills to produce something valuable. (1) and (6) are highlighted in the above graph because they should be on every onramp: you always need to communicate the value of your project (such as via websites, social media, etc) and validate the people who use it successfully (such as with rewards, engagement, and opportunities). The latter is especially important for building lasting relationships with your community.

Think about how to simplify the overall onramp (you should explore how muntzing can help here). Then, ensure that each transition from one step to the next step is logical and try to understand and resolve where people get stuck.

If you don't do this, you will struggle to build a userbase for your project, which is a critical requirement before you can consider developing a contributor-base.

#3. What are your primary goals for open sourcing it?

The next question is why are you are open sourcing your project in the first place? From a company perspective this can vary and will often include one or more of the following:

This is where things can get complex: open source projects can often lead to many of the benefits listed above, but it is not just the nature of being open source that will drive these benefits, it is the focused strategy efforts you put in place that will.

For example, if your goal is "increasing engineering contributions", putting code in a repo will not merely lead to this. Clear developer on-boarding, solid documentation, building meaningful community relationships with developers, developer focused content and outreach, and other efforts will help drive this growth.

The risk some companies face here is that they think of the value of open source primarily from their own perspective, but don't focus enough on what value their users want to experience too. How can you build an open source community that gives your users greater information, flexibility, and communication with the project and your team? How can your users play a more meaningful role in the project? If you build an environment with your users' needs in mind, you will build a a far more engaging and valuable community in general.

#4. What new skills and resources do you need to build in your company to do this work well?

It took me far too long to realize that a significant determining factor of community success is not just making the right strategic choices, but also baking those skills effectively into an organization.

For many companies, switching to an open source model is a significant change of workflow, policy, and how you incentivize your team. Aside from picking the right set of open source strategic steps (such as how you publish code, manage issues, build community engagement and growth etc.), you should also plan for how to bake these skills and expertise into your teams.

Wrong kind of baking.
Credit.

An an example, one key element of being an open source project is receiving and responding to pull requests with new features and fixes. This requires your team members to be able to review those PRs, test them, provide constructive feedback, and approve or reject the contribution based on merit. It requires calm and constructive feedback, often with people you don't know and trust yet. It requires the overall code review process to happen end-to-end out in the open. Overall this needs a nuanced set of skills such as peer review, technical collaboration, open build management, and other pieces.

For companies less familiar with open source, this is all going to seem a bit weird and uncomfortable. Your team members are going to hesitant to engage, not only because it is new, but they also don't want to put a foot wrong and get in trouble. This is entirely normal.

As such, think about how to break these skills down into simple pieces, provide the right level of training and support, and how to mentor and support people through this transition. Help them to build a habit around participation, and develop incentives, rewards, and other mechanisms to help them naturally orient to an open workflow and enjoy engaging in it.

Open source is an enormously powerful model, but focusing on these core product questions is an important part of the process. What other considerations should companies be making? Share them in the comments…

The post Open Source Won't Save A Subpar Product appeared first on Jono Bacon.

22 Apr 2019 6:12am GMT

Gustavo Silva: Disco Dingo Thoughts

Hello everyone.

After over a year without posting, I am back to review the latest release of Ubuntu, Disco Dingo 19.04.

Those already around me know I love Linux and my favourite linux distribuition is Ubuntu.

One of the reasons Ubuntu is my favourite is how simple and compatible it is with pretty much all devices I have tried installing. Except my laptop, but that's due to the graphics card.

But hey, I fondly received the news that now we can select the option to automatically set nomodeset and other convenient tools when running the setup. For me, this means a major win. I previously had to set nomodeset manually and after installation I had to immediately modifiy some options in the grub's defaults (namely set the acpi=force) but now, with this new option, the installation process which was already smooth, become (melted) butter. Thank you, honestly, person who remembered to include this option. This seems like a feature that will stick to Ubuntu 20.04, so I'm happy to now a LTS version will become even simpler to install too, so that's great.

The UI and custom-Gnome experience has been improved as well, in this custom flavour of Gnome. We now have a few more options for customization, including dark options of the themes but I am definitely pleased to say that the Gnome shell, in Ubuntu 19.04, really looks great.

Finally, Ubuntu 19.04 comes with the 5 series of the kernel, meaning we are getting cutting edge version of the kernel. People everyone are mentioning the fact that is given a significant battery duration boost, although I haven't tried it. I use my computer mainly at home and it's always plugged in. Personally though, using a more recent kernel is awesome, as I am more balanced torward freshness of the software in favour of stability (but not to the point things break on a daily basis). In fact, the entire experience feels improved, sharper, more responsive than before. The system is the same, so there is nothing related to hardware changes. They also removed Python 2 from the base installation but I feel that was expected as Python 2 will stop being supported very soon.

I'll take my chances and simply say that Ubuntu is making significant progress in becoming the linux distribution of choice for a lot of people. It just works, whether you have a potato computer, or a high-end beast. Great job, everyone.

Thanks for reading gsilvapt

22 Apr 2019 12:00am GMT

21 Apr 2019

feedPlanet Ubuntu

Kubuntu General News: Trusty 14.04 LTS end of life, and end of Kubuntu support for Xenial 16.04 LTS

As the newly released Kubuntu 19.04 makes its way into the world, inevitably other things come to their end.

Kubuntu 14.04 LTS was released in April 2014, and reaches 'End of Life' for support on 25th April 2019. All Kubuntu users should therefore switch to a newer supported release. Upgrades from 14.04 to a newer release are not advised, so please install a fresh copy of 18.04 or newer after running a backup of all your data.

Kubuntu 16.04 LTS was released on 21st April 2016, and was supported for Kubuntu for a period of year 3 years.* Kubuntu 16.04 LTS support therefore ends 21st April 2019, and users are invited to upgrade to 18.04 LTS, or perform a fresh install of that or newer release.

The Kubuntu team would thank users of both releases, especially for the amazing additional community support on IRC, forums, mailing lists, and elsewhere.

* https://lists.ubuntu.com/archives/ubuntu-release/2016-April/003704.html

21 Apr 2019 9:59pm GMT

Podcast Ubuntu Portugal: Ep. 54 – Disco com o Dingo

Mascote do Ubuntu 19.04 - Um dingo numa mesa de misturaDisco Dingo por Sylvia Ritter

As nossas aventuras, falámos do Ubuntu 19.04 Disco Dingo e da Ubucon Portugal 2019. Mas claro que também passámos pelas notícias, por alguns snaps e pela agenda.
Já sabes: ouve, subscreve e partilha!

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.

Atribuição e licenças

A imagem de capa (Disco Dingo) foi criada por Sylvia Ritter, e é utilizada com a sua gentil e explicita permissão, podendo ser encontrada em: https://www.deviantart.com/sylviaritter/art/Disco-Dingo-786327017
Mais trabalhos feitos pela Sylvia Ritter, incluindo imagens de outras mascotes de releases de Ubuntu, podem também ser encontrados no seu sítio web: https://www.sylvia-ritter.com/
Podem apoiar o trabalho da Sylvia Ritter na sua página de Patreon em: https://www.patreon.com/sylviaritter
E podem também seguir nas redes sociais:
Tweets by sylvia_ritter
https://www.facebook.com/SylviaRitterArt

A música do Genérico: "Stringed Disco", por Kevin MacLeod (incompetech.com), está licenciada com Creative Commons: By Attribution 3.0 License (http://creativecommons.org/licenses/by/3.0/)
https://incompetech.com/music/royalty-free/index.html?isrc=USUAN1100059

Este episódio está licenciado 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.

21 Apr 2019 8:52am GMT

Ubuntu Studio: Ubuntu Studio 18.04 Extended Support

Back in April 2018, Ubuntu Studio 18.04 was released as a non-LTS (Long-Term Support) version, which limited its support cycle to end January 2019. This was due to a number of factors, from the involvement of the team members at the time to the number of team members. In January 2019, the team came up […]

21 Apr 2019 1:55am GMT

20 Apr 2019

feedPlanet Ubuntu

Jonathan Carter: Debian project leader elections 2019

A few weeks ago, after a few days of internal turmoil on the matter, I committed to running for DPL.

The original nomination period was the week before, with no one stepping up for the position and with our current leader indicating that he wouldn't be available to serve another term. This resulted in a bit of a knee-jerk reaction and slight panic, with threads popping up on the debian mailing lists pondering things like what a leaderless Debian would look like and whether we perhaps need more of a team than a single person to be the leader the project. There was also some discussion about burnout and whether it's even fair to put so much pressure on a single person, and whether it's possible to delegate more of the DPL's responsibilities. The press also picked up on this and there were a few big stories on the matter that lead some to be slightly nervous on the matter.

Of course (as the LWN article pointed out), Debian's constitution is quite thorough and has made provision for cases like these. If no one steps up, the nomination period is extended for another week, and it only took one such extension to produce 5 new candidates (of which one retracted soon afterwards due to time commitments).

I mentioned internal turmoil at the beginning of the post, this was because up until a few days before my self-nomination, I've been very confident, and consistently so for a very long time, that I never want to run for DPL. The work that I care about and spend most attention on doesn't at all require me being a DPL. Also, having more responsibility in areas that I'd rather let others take care of sounded a bit daunting. I'd much rather spend time on technical and more general community issues than very specific interpersonal problems or administrative tasks like reading and approving budget proposals, sending out developer certificates, etc. On top of that, I was aware that running for DPL and opening myself like that means that I open myself to a very wide array of critique, that people might put everything I say under a microscope and try to tear it apart, and that running for DPL means being prepared for that.

Despite that turmoil, a small nagging part kept asking the questions "But what if?", what if I were DPL, what would I do? What would I change? What would I do as DPL that would make Debian better, and better as a DPL than I just could as a normal debian developer? These questions helped form in my head what my platform would look like, why I wanted to run for DPL, and how the rest of my campaign would shaped up. This year is also unique for me compared to previous years in that I will actually have time over the next year to focus on DPL-like activities. That, combined with the plans that were shaping up that I'm very enthusiastic about, convinced me that it's time to step up and proceed with my self-nomination.

Directly after the nomination period, the campaign period starts. There are surprisingly few rules (or even guidance) regarding the campaign period, the majority of it is where Debian developers (or anyone really, but mostly DDs) ask questions to the DPL candidates about their stance and policy on certain matters, how they plan to take action and often a few really tough hypothetical situations. Some questions even took advantage of the fact that April fools day falls in the campaign period, which led to some odd and interesting questions. Overall, I really enjoyed the campaign period. I was preparing myself for the worst case scenario before campaigning started, but what actually happened next astonished me. We had all kinds of Debian developers coming forward with high quality, productive discussions on all kinds of aspects which ranged from internal technical policies, how we work with upstreams, community matters, diversity, the DPL role itself, how Debian is changing and how to keep it relevant, community turnover, how we deal with money, how we market ourselves and so one. It was productive discussion and I enjoyed it.

Regardless of the outcome of this election, I'm very happy that I stepped up as a DPL candidate, and I'm very satisfied with how my campaign went and how I answered my questions. I'm also very happy that the elections turned out so vibrant and productive and I dare say even exciting. I hope that this will continue to happen for future elections, because it's clear to me that a productive election period is good for the health of Debian.

In the future, someone may be reading this and ponder "Should I run for DPL?". My advice would be to first take some stock and figure out if you're at a place in your life where you can actually do that (Did you just start a new job? Would your employer support you? Did you recently get married, have kids? How's your health? Can you afford to spend lots of unpaid time doing DPL work? etc…) and then also consider why you'd want to be DPL and what you'd like to achieve with such a role. If you weigh up all the aspects and it still feels right for you, then by all means go for it. In my opinion, even if you're not elected you still help make Debian better by participating in the election process.

Voting closes in around 12 hours at the time of writing this. Good luck to all the candidates and thank you to everyone who participated in making this such a fantastic and surreal experience!

2019-04-21: Update: Congratulations to Sam Hartman who is our new DPL! We've been talking off-list throughout the election process and Sam knows he has my full support and we even plan to collaborate on certain areas, more news to follow in the near future.

20 Apr 2019 12:00pm GMT

19 Apr 2019

feedPlanet Ubuntu

Riccardo Padovani: Responsible disclosure: improper access control in Gitlab private project.

As I said back in September with regard to a responsible disclosure about Facebook, data access control isn't easy. While it can sound quite simple (just give access to the authorized entities), it is very difficult, both on a theoretical side (who is an authorized entity? What does authorized mean? And how do we identify an entity?) and on a practical side.

This issue was firstly reported on HackerOne and was managed on the Gitlab issues' tracker. Both links are now publicly accessible.

Summary of the issue

The second step could happen for a lot of different reasons:

When an admin removes a user from a private group, there is no indication that the user still has access to private projects, if their role was changed.

Impact

User can still see all resources of a project of a secret group after they have been removed from the parent's group.

Timeline

Bounty

Gitlab awarded me a $2000 bounty award for the disclosure.

If you follow my blog, you know I deeply love Gitlab: I contribute to it, I write blog posts, and I advocate for it any time I can. Still, I think this experience was awful, to say the least. There was a total lack of communication by their side, they thought they fixed the issue the first time, but actually, it wasn't fixed. If they had communicated with me, I would have double checked their work. After that, they deployed the fix and went public, without telling me. I was not interested in the bounty (for which I am grateful), I reported the issue because I care about Gitlab. Nonetheless, my love for Gitlab is still the same! I just hope they will improve this part of communication / contributing to Gitlab: in the last couple of years the community around the project grew a lot, and they are doing amazing with it, maybe the Community team should step in and help also the security community?

For any comment, feedback, critic, write me on Twitter (@rpadovani93) or drop an email at riccardo@rpadovani.com.

Regards,
R.

19 Apr 2019 6:00pm GMT

Jonathan Riddell: Kipi Plugins 5.9.1 Released

Kipi Plugins is a set of app plugins for manipulating images. They use libkipi which is released as part of KDE Applications. It used to get standalone releases and was then moved to be part of Digikam releases. Since Digikam 6 they have been deprecated by Digikam in favour of their new plugin framework DPlugins. While in KDE Frameworks the Purpose Framework is another newer project covering similar features.

However Kipi Plugins are still supported by KDE apps KPhotoAlbum, Gwenview, Spectacle so they shouldn't disappear yet.

I've made a new release available for download now.

https://download.kde.org/stable/kipi-plugins/

Versioned 5.9.1 because it is little changed from the previous release done inside Digikam which was 5.9.0.

Tagged commit b1352149b5e475e0fbffb28a7b5fe13503f24dfe

Sha256 Sum: 04b3d31ac042b901216ad8ba67dafc46b58c8a285b5162b51189833f6d015542

Signed by me Jonathan Riddell <jr@jriddell.org>

This will become part of KDE Applications in its next release scheduled for August and will follow the KDE Applications version numbers.

Facebooktwitterlinkedinby feather

19 Apr 2019 11:47am GMT

The Fridge: Ubuntu 19.04 (Disco Dingo) released

Codenamed "Disco Dingo", 19.04 continues Ubuntu's proud tradition of integrating the latest and greatest open source technologies into a high-quality, easy-to-use Linux distribution. The team has been hard at work through this cycle, introducing new features and fixing bugs.

The Ubuntu kernel has been updated to the 5.0 based Linux kernel, our default toolchain has moved to gcc 8.3 with glibc 2.29, and we've also updated to openssl 1.1.1b and gnutls 3.6.5 with TLS1.3 support.

Ubuntu Desktop 19.04 introduces GNOME 3.32 with increased performance, smoother startup animations, quicker icon load times and reduced CPU+GPU load. Fractional scaling for HiDPI screens is now available in Xorg and Wayland.

Ubuntu Server 19.04 integrates recent innovations from key open infrastructure projects like OpenStack Stein, Kubernetes, and Ceph with advanced life-cycle management for multi-cloud and on-prem operations, from bare metal, VMware and OpenStack to every major public cloud.

The newest Ubuntu Budgie, Kubuntu, Lubuntu, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, and Xubuntu are also being released today.

More details can be found for these at their individual release notes:

https://wiki.ubuntu.com/DiscoDingo/ReleaseNotes#Official_flavours

Maintenance updates will be provided for 9 months for all flavours releasing with 19.04.

To get Ubuntu 19.04

In order to download Ubuntu 19.04, visit:

http://www.ubuntu.com/download

Users of Ubuntu 18.10 will be offered an automatic upgrade to 19.04 if they have selected to be notified of all releases, rather than just LTS upgrades. For further information about upgrading, see:

http://www.ubuntu.com/download/desktop/upgrade

As always, upgrades to the latest version of Ubuntu are entirely free of charge.

We recommend that all users read the release notes, which document caveats, workarounds for known issues, as well as more in-depth notes on the release itself. They are available at:

http://wiki.ubuntu.com/DiscoDingo/ReleaseNotes

Find out what's new in this release with a graphical overview:

http://www.ubuntu.com/desktop
http://www.ubuntu.com/desktop/features

If you have a question, or if you think you may have found a bug but aren't sure, you can try asking in any of the following places:

#ubuntu on irc.freenode.net
http://lists.ubuntu.com/mailman/listinfo/ubuntu-users
http://www.ubuntuforums.org
http://askubuntu.com

Help Shape Ubuntu

If you would like to help shape Ubuntu, take a look at the list of ways you can participate at:

http://community.ubuntu.com/contribute

About Ubuntu

Ubuntu is a full-featured Linux distribution for desktops, laptops, netbooks and servers, with a fast and easy installation and regular releases. A tightly-integrated selection of excellent applications is included, and an incredible variety of add-on software is just a few clicks away.

Professional services including support are available from Canonical and hundreds of other companies around the world. For more information about support, visit:

http://www.ubuntu.com/support

More Information

You can learn more about Ubuntu and about this release on our website listed below:

http://www.ubuntu.com

To sign up for future Ubuntu announcements, please subscribe to Ubuntu's very low volume announcement list at:

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

Originally posted to the ubuntu-announce mailing list on Thu Apr 18 13:13:39 UTC 2019 by Adam Conrad, on behalf of the Ubuntu Release Team

19 Apr 2019 7:15am GMT

18 Apr 2019

feedPlanet Ubuntu

Xubuntu: Xubuntu 19.04 released!

The Xubuntu team is happy to announce the immediate release of Xubuntu 19.04!

Xubuntu 19.04 is a regular release and will be supported for 9 months, until January 2020. If you need a stable environment with longer support time, we recommend that you use Xubuntu 18.04 LTS instead.

The final release images are available as torrents and direct downloads from xubuntu.org/getxubuntu/

As the main server might be busy in the first few days after the release, we recommend using the torrents if possible.

We'd like to thank everybody who contributed to this release of Xubuntu!

Highlights and Known Issues

Highlights

Known Issues

For more obscure known issues, information on affecting bugs, bug fixes, and a list of new package versions, please refer to the Xubuntu Release Notes.

The main Ubuntu Release Notes cover both many of the other packages we carry and more generic issues.

Support

For support with the release, navigate to Help & Support for a complete list of methods to get help.

18 Apr 2019 4:55pm GMT

Lubuntu Blog: Lubuntu 19.04 (Disco Dingo) Released!

Thanks to all the hard work from our contributors, Lubuntu 19.04 has been released! With the codename Disco Dingo, Lubuntu 19.04 is the 16th release of Lubuntu and the second release of Lubuntu with LXQt as the default desktop environment. Support lifespan Lubuntu 19.04 will be supported for 9 months, until January 2020. If you […]

18 Apr 2019 4:52pm GMT

Kubuntu General News: Kubuntu 19.04 is released today

Kubuntu 19.04 has been released, featuring the beautiful Plasma 5.15 desktop from the KDE community.

Code-named "Disco Dingo", Kubuntu 19.04 continues our proud tradition of integrating the latest and greatest open source technologies into a high-quality, easy-to-use Linux distribution.

The team has been hard at work through this cycle, introducing new features and fixing bugs.

Under the hood, there have been updates to many core packages, including a new 5.00-based kernel, Qt 5.12, KDE Frameworks 5.56, Plasma 5.15.4, and KDE Applications 18.12.3

Kubuntu has seen some exciting improvements, with newer versions of Qt, updates to major packages like Krita, Kdeconnect, Kstars, Latte-dock, Firefox and LibreOffice, and stability improvements to KDE Plasma.

For a list of other application updates, upgrading notes and known bugs be sure to read our release notes:

https://wiki.ubuntu.com/DiscoDingo/ReleaseNotes/Kubuntu

Download 19.04 or read about how to upgrade from 18.10.

18 Apr 2019 4:28pm GMT

Ubuntu Podcast from the UK LoCo: S12E02 – Light Force

This week we have been upgrading disk drives (again) and playing Elite Dangerous. We discuss Mark's homebrew Raspberry Pi based streaming box, bring you some command line love and go over your feedback.

It's Season 12 Episode 02 of the Ubuntu Podcast! Alan Pope, Mark Johnson and Martin Wimpress are connected and speaking to your brain.

In this week's show:

rdfind ./somedir

That's all for this week! You can listen to the Ubuntu Podcast back catalogue on YouTube. If there's a topic you'd like us to discuss, or you have any feedback on previous shows, please send your comments and suggestions to show@ubuntupodcast.org or Tweet us or Toot us or Comment on our Facebook page or comment on our sub-Reddit.

18 Apr 2019 2:00pm GMT