Español

Português

Bahasa Indonesia

فارسى

Русский язык

Dear community,

openSUSE has been known for years as an amazing, vast and buzzing community. But after many discussions with the many linguistic groups that compose the openSUSE mosaic, we feel that more could be done to facilitate communication and exchanges. We feel this is what makes a community of communities special: it thrives when all groups, from big to small, stick together and share the pleasure of sharing – be it knowledge, emotions or stories.

Nice words don’t do much alone, so the first two concrete changes we want to make:

1. news-o-o: We want to have all “community news” translated to the four most spoken languages within the community (Indonesian, Spanish, Portuguese, Russian – this is only a beginning, get in touch with us if you want to propose yourself as a translator for more languages)
2. a new community newsletter: Getting inspiration from our ancestor, we want to create a community-wide newsletter that will, among other things:
   • feature amazing individuals from all over the community, putting the spotlight on what they do and how they do it, via interviews or self-coverage
   • share useful tutorials and guides on how to use your openSUSE system and how you can quickly get started with contributing
   • feature interesting packages that may use some love
   • expose places in the community where your interests and skills would be best put to use
   • announce community events & activities, so that you have a chance to meet up geekos of different shades of green
   • … overall, a finely curated collection of blog posts, articles and reviews that appeared in the last weeks or so, to make certain things stick out from the inescapable flow of time.

We are almost ready to get started, but we are still looking for 1-2 translator(s) to Russian.

Call to ‘“veteran contributors”: If you are a package maintainer or an infrastructure volunteer and you feel like your workflow could be improved or “parallelized” with help from additional volunteers, please do get in touch. Formation and delegation are a good way of strengthening bonds between communities.

As for working together, we will be adopting a flat, decentralized organization model, to avoid burdening a few people with a role that would be left hanging should they move on to other things. So there is no reason to worry that joining us will commit you to a year of weekly efforts. If you come up with a good idea, we’ll help you realize it, and that is all! No one will pressure you.

So if you are interested in helping us, or in being featured, or in getting involved in any way, please do ring us and tell us your story!

Your news & community friends

• https://t.me/openSUSE_newscom
• https://matrix.to/#/#newscom:opensuse.org
• https://discord.gg/opensuse#newscom

Why is that phone so special? My wife asked me. I was exited like a child with my shiny new toy: the PinePhone KDE Community Edition.

So how do you explain the history of failing efforts to get ‘real’ Linux on a smartphone in 5 minutes? How do you explain the difficulties of developing an operating system for the always changing ARM ecosystem?

I tried: It’s not normal that you can install an Operating System on a phone. Normally you have 2 choices: you buy an Android phone or you buy an Apple iOS phone. In both cases, the phone hardware (read: boot loader) is locked down. So you can’t change the Operating System. At least not easily (because you can root some Android phones).

Over the last 10 years, there have been many companies that tried (and failed) to develop their own Operating System that can compete with Android and/or Apple iOS. In historical order:

• Nokia Meamo/MeeGo in 2009/2010
• Palm/HP WebOS in 2009/2010
• Microsoft Windows Phone 8 / 8.1 / 10 in 2012/2014/2015
• BlackBerry 10 in 2013
• Mozilla Firefox OS in 2014
• Canonical Ubuntu Touch from 2014-2017
• Jolla Sailfish OS / X (on Sony Experia) from 2013 – present
• Samsung Tizen from 2017 – present

These companies failed to gain any traction in the market. That list makes it abundantly clear that it’s hard to develop a successful smartphone hardware and software combination.

But the open source community doesn’t take No for an answer. The great thing about the free and open source movement is that commercial success is not a requirement for continued development. Which means that 3 open source communities are still hacking to develop a ‘real’ open source Mobile Operating System:

• Ubuntu Touch, was continued by the UBPorts project in April 2017
• KDE Plasma Mobile, started development in July 2015
• Phosh, a GNOME shell for Purism Pure OS, started development in 2017

This development effort would be in vain if there was no smartphone that could run this software. But 2 hardware initiatives started roughly around the same time, and offered to build a true open source friendly smartphone:

• Purism Librem 5, announced in August 2017
• Pine64 PinePhone, announced in October 2018

This resulted in a perfect storm, because the Librem 5 started shipping in November 2019 and the PinePhone started shipping in January 2020. Both devices released in a rough state, but both software and hardware have improved over the months in 2020.

I played around with KDE Plasma Mobile during the FOSDEM conferences of 2016, 2017, 2018 and 2019. Because of the Covid-19 pandemic, I couldn’t attend in 2020 and 2021. So that is my excuse to purchase a PinePhone KDE Community Edition, which was announced in December 2020. At the end of January 2021, I received my PinePhone with Manjaro Linux and KDE Plasma Mobile.

Unboxing the PinePhone

For me this was a very exiting event. I was very curious how the PinePhone would feel in real life. I expected it to be very plastic feeling. It did feel that way, but it didn’t feel cheap. It was well constructed.

I particularly like the inside of the phone. I like the physical dip (kill) switches, that are tucked neatly into the back of the phone. Personally, I will never use these, because I just don’t care. The same thing goes for the Pogo pins. Cool that they are there, but I will never use them. What I will use is the SD card slot. But I still need to figure out how to mount that persistently.

The screen is also fine. With 6 inches, the screen is sufficiently large. It has a resolution of 720×1440 pixels, which means that there is enough detail. And the colors are fine; for 150-200 dollars you can’t expect an AMOLED quality experience. The phone is also relatively thin.

Finally it has an USB-C connector on the bottom, which is a future proof solution. The front camera is 2 Megapixels and the back camera is 5 Megapixels. I don’t know how good they are, because the firmware and camera software are still in heavy development. In short: they don’t work except for showing a black and white image.

The software experience

After I put in the SIM card, I booted up the phone. The login screen is very nice, with the clock on the center of the screen. However, entering the PIN code (this always needs to be numbers) is a bit awkward because the ‘0’ is located on the right instead of located at the bottom, where you would expect it to be.

When you have unlocked the phone, it looks like a standard Android experience. You have a app drawer that you open by swiping up. Hold on to an icon and you can place it on the home screen. Touch the icon and it will open that app. Long press the home screen and you can add widgets or change the wallpaper. I haven’t found a way to setup multiple virtual desktop screens, so you can’t swipe left or right. You can add an Activities widget or a Pager widget, but it doesn’t do much at the moment.

If you swipe down, you will reveal the control center. Not everything is fleshed out. So sometimes touching an icon will result in you being redirected to the settings app. The flashlight works however! And the night color option works as well.

How to kill your PinePhone on Day 1

The first thing that I wanted to do was to update the software. I knew that the phone was running Manjaro linux. I didn’t have any experience with Manjaro, so I searched the internet how to update the system and found this handy instruction on the PinePhone wiki. This worked like a charm; via the Terminal app I was able to update my system. It was very cool to see all updates on the command line interface.

Next I wanted to install some software. And I wanted to use a GUI Software Manager. So I installed Pamac. That went fine. And although it didn’t fit my screen fully, I could search and install software. So I started by installing:

• Firefox
• Signal-desktop

The install didn’t go as planned. After restarting the phone, it didn’t boot anymore. Which meant I had turned my new toy into a brick. At first I was a bit disheartened. But then I read that the PinePhone always prefers the SD card over the internal memory. Which means that I could easily replace the operating system with something new. I decided that this was the perfect opportunity to install openSUSE on my PinePhone.

Installing openSUSE Tumbleweed on the PinePhone

I followed these installation instructions. The first thing I did was download the Jumpdrive image. I put in a small MicroSD card into my laptop and when I doubleclicked the image in Dolphin, this opened automatically in Gnome Disks and offered me to write it to the SD card. Then I put the SD card in the PinePhone and plugged in the USB-C connector. And I started up the phone.

The next step was to write the openSUSE image to the internal memory (eMMC) of the PinePhone. Again, I started downloading the openSUSE image, which you can find here. I have chosen to go with the KDE Plasma Mobile version, because I am used to KDE as my regular Desktop Environment as well. The next step is to Unzip the file, by opening the file with Ark.

And then click twice on the Extract button.

The next step is to open Disks and to select the dots and then click on Restore Disk Image.

The next step is to select the raw (Unzipped) image. You can simply ignore the error that your SD card (which is the internal eMMC memory) is bigger than the image that you are about the write. That is logical, because you are writing a 4GB image to a 16GB disk. And you will use (read: format) the full disk for that. So click Restore to continue.

Gnome Disks will show you the progress. When everything is done, you will see that the internal memory of the PinePhone is now divided into 3 partitions and some empty space.

The next step is to enlarge the ROOT partition. But you need a program named f2fs-tools to be installed for that to work. Use YaST to install these packages. After that use Gnome Disks to extend the partition. In the end you should have a ROOT partition of about 15 GB.

The next step is to remove the Jumpdrive MicroSD card from your PinePhone and boot the device. You should see the glorious openSUSE logo appearing.

Swipe up and put in the default Pin-code of 1234. Then put in the default Pin-code of your SIM card.

You will now see the Home screen with a recognizable openSUSE green wallpaper. A few tips to do first:

• Use Discover to update your phone to the latest version
• Use Discover to install all kinds of apps
• Change your password via the terminal (sudo passwd)

When changing your password, make sure that you use only numbers!!! Because your root password is also the Pin-code for unlocking the phone. Of course openSUSE will complain; just ignore that and enter the 4 number password again.

Conclusion

I am really happy with my PinePhone. Its a great toy for experiencing the state of Plasma Mobile and Phosh. For me it is also a delight that I can use openSUSE Tumbleweed, as I am familiar with Zipper for the command line. In the future, I will try out Phosh to see how far that has progressed. But that is a topic for another blog post.

Published on: 8th March 2021

“We got lucky”—it’s one of those phrases I listen out for during post incident or near-miss reviews. It’s an invitation to dig deeper; to understand what led to our luck. Was it pure happenstance? …or have we been doing things that increased or decreased our luck?   

There’s a saying of apparently disputed origin: “Luck is when preparation meets opportunity”. There will always be opportunity for things to go wrong in production. What does the observation “we got lucky” tell us about our preparation? 

How have we been decreasing our luck?

What unsafe behaviour have we been normalising? It can be the absence of things that increase safety. What could we start doing to increase our chances of repeating our luck in a similar incident? What will we make time for? 

“We were lucky that Amanda was online, she’s the only person who knows this system. It would have taken hours to diagnose without her” 

How can we improve collective understanding and ownership? 

Post incident reviews are a good opportunity for more of the team to understand, but we don’t need to wait for something to go wrong. Maybe we should dedicate a few hours a week to understanding one of our systems together? What about trying pair programming? Chaos engineering?

How can we make our systems easier to diagnose without relying on those who already have a good mental model of how they work? Without even relying on collaboration? How will we make time to make our systems observable? What would be the cost of “bad luck” here? maybe we should invest some of it in tooling? 

If “we got lucky” implies that we’d be unhappy with the unlucky outcome, then what do we need to stop doing to make more time for things that can improve safety? 

How have we been increasing our luck? 

I love the extreme programming idea of looking for what’s working, and then turning up the dials. 

Let’s seek to understand what preparation led to the lucky escape, and think how we can turn up the dials.

“Sam spotted the problem on our SLIs dashboard”

Are we measuring what matters on all of our services? Or was part of “we got lucky” that it happened to be one of the few services where we happen to be measuring the things that matter to our users? 

“Liz did a developer exchange with the SRE team last month and learned how this worked”

Should we make more time for such exchanges or and personal learning opportunities? 

“Emily remembered she was pairing with David last week and made a change in this area”

Do we often pair? What if we did more of it?

How frequently do we try our luck?

If you’re having enough production incidents to be able to evaluate your preparation, you’re probably either unlucky or unprepared ;)

If you have infrequent incidents you may be well prepared but it’s hard to tell. Chaos engineering experiments are a great way to test your preparation, and practice incident response in a less stressful context. It may seem like a huge leap from your current level of preparation to running automated chaos monkeys in production, but you don’t need to go straight there. 

Why not start with practice drills? You could have a game host who comes up with a failure scenario. You can work up to chaos in production. 

Dig deeper: what are the incentives behind your luck?

Is learning incentivised in your team, or is there pressure to get stuff shipped? 

What gets celebrated in your team? Shipping things? Heroics when production falls over? Or time spent thinking, learning, working together?

Service Level Objectives (SLOs) are often used to incentivise (enough) reliability work vs feature work…if the SLO is at threat we need to prioritise reliability. 

I like SLOs, but by the time the SLO is at risk it’s rather late. Adding incentives to counter incentives risks escalation and stress. 

What if instead we removed (or reduced) the existing incentives to rush & sacrifice safety. Remove rather than try to counter them with extra incentives for safety?

The post We got lucky appeared first on Benji's Blog.

I have received quite the number of comments about emulating the Game Boy on modern hardware and all the work that is going into it. I learned so much about the extensive community around emulating Game Boy games and the technology, research and absolute passion that goes into it. Though I was given many suggestions, … Continue reading mGBA | Game Boy Emulation on Linux →

Dear Tumbleweed users and hackers,

This week has proven to be challenging for Tumbleweed. We have built and tested 6 snapshots, and only 2 of them were of sufficient quality to send out to the users. Of course, that means our QA infrastructure is well suited in protecting you, the users, from running into trouble – and that is the best thing we can show with this.

The two snapshots published were 0227 and 0302, containing these interesting changes:

• NetworkManager 1.30 – with WPA3 support
• The YaST stack update, as recently announced by the YaST team
• Mozilla Firefox 86.0
• Mozilla Thunderbird 78.8.0
• KDE Plasma 5.21.1
• Dracut 053
• krb5 1.19.1
• pipewire 0.3.22: pipewire-pulseaudio should mostly be able to replace PulseAudio
• podman 3.0.1

A big chunk of what was announced last week was thus delivered, a few things are still on the todo – together with a few new things:

• Linux kernel 5.11.2
• openssl 1.1.1i, based on centralized crypto-policies package
• KDE Plasma 5.21.2
• glibc fix for our i586 users
• GCC 11 as the default compiler

openSUSE Leap has entered into the beta release phase today for its 15.3 minor version.

This openSUSE Leap 15.3 version is a solidified release that focuses more on the building of the distribution rather than refreshing the distribution’s packages, but there are some significant changes to the distribution.

Many of the packages will remain the same as those in openSUSE Leap 15.2 with a bit of hardware enablement and security backports. An updated version of glibc brings some Power10 support and the Xfce desktop users will have the new 4.16 version. The distribution also gains adds s390x architecture.

The biggest change for this release is how Leap is built and its relationship with SUSE Linux Enterprise. Leap transitioned to a new way of building openSUSE Leap releases in the fall of 2020 through a prototype project called Jump. The Jump prototype was used as a proof of concept, but no longer exists; it did prove to work at building a distribution and bringing the code streams of both openSUSE Leap and SLE closer together. The proof of concept was implemented for building the release of openSUSE Leap 15.3 as seen in the beta release today. Building Leap on top of binary packages from SLE, which was part of the rationale for the Jump prototype, allows for easy development on a community release to be put into production on an enterprise release should the need arise.

The changes make the migration from openSUSE Leap 15.3 to SLE 15 Service Pack 3 practically instantaneous and there are no socket or virtual machine limitations. A little more than 50 packages are not identical with SLE, but these are mostly branding, patterns and openSUSE branding packages.

Entering this beta phase, testers are encouraged to test the migration from Leap to SLE. People testing the beta are encouraged to record their Leap Beta testing efforts on the following spreadsheet: https://docs.google.com/spreadsheets/d/1AGKijKpKiJCB616-bHVoNQuhWHpQLHPWCb3m1p6gXPc/edit#gid=801313279

Leap beta testers have an option to receive a T-shirt, so make sure to fill in all the proper information and bug reports to get one. Then send an email to ddemaio (at) opensuse.org with your address, size and name corresponding to the spreadsheet. Please make the subject title “beta test t-shirt”.

Bugs should be reported on openSUSE’s bugzilla and if any are found on SLE should be reported to SUSE’s bugzilla products for desktop, server and High Availability.

Leap has a rolling development model during both its Alpha and Beta phases. After the gold master and Public Availability of Leap is released, the rolling development model stops; the release then shifts into a supported release model with maintenance and security updates until its End of Life (EOL). Leap has an extended life cycle greater than 12 months per release. Leap ideal for desktop and server environments.

There are no concrete milestones in the Leap rolling development model. As bugs are fixed and new packages introduced or excluded, snapshots of the latest beta phase builds will be released once they pass openQA testing; this will take place over the next few months as the road map shows openSUSE Leap 15.3 will be have a Release Candidate in late April and the Gold Master on May 21, which will be follow by a public release on June 2. The documentation and translations deadline is May 14.

Architectures available for testing include x86_64, aarch64, PowerPC and s390x. People interested in armv7 and other architectures should read the announcement about openSUSE Step.

Those interested in beta testing images for openSUSE Leap 15.3 Windows Subsystem for Linux can contact the Leap release manager Luboš Kocman or the factory mailing list.

TL;DR

Operating systems let you customize the sensitivity of the microphone allowing you to suppress environmental noise such as keyboard strokes. Video conferences software unfortunately tends to override such settings using autogain making your customization void. While some video conferencing tools let you control autogain via the settings, Jitsi does not have such an option.

However, you can use https://your.jitsi.server/someroom#config.disableAGC=true when joining your Jitsi meetings to disable autogain and have more control over your microphone.

It has been three weeks since the previous development report from the YaST Team. That’s one week more than our usual cadence, since most of the team was booked during four days in an internal SUSE workshop. But fear no more, we are back and loaded with news as usual. This time we bring:

• Support to enable and configure SELinux during installation
• A revamped interface for configuring wireless network devices
• Usability improvements in several areas
• A new “hidden level” in the installer with advanced tools ;-)

You may know that both the SUSE and openSUSE families of operating systems include container-oriented members, namely openSUSE MicroOS and SLE Micro. In order to make them even more awesome, we got the request to make possible to propose and configure the usage of Security-Enhanced Linux, more widely known as SELinux, during the (auto)installation. This is a complex change affecting several parts of YaST and various versions of (open)SUSE, but you can get a good overview in the description of this pull request which includes some screenshots that may be worth a thousand words. Right now, the feature may look different on each one of the distributions due to the different state of SELinux on them. While in SLE Micro the new setting is visible during installation and activated at its more restrictive level, in others it may look more permisive or even not be presented at all. We expect things to consolidate during the upcoming weeks.

And talking about things that take their time, for a long time we had wanted to improve the usability of the configuration of wireless network adapters. Finally we found the time to reorganize the corresponding tab in the YaST Network module, improving the mechanism to select a wireless network and automatically pre-filling as much information as possible. You can see the result in the following animation and in the detailed pull request with the usual before-and-after screenshots.

That’s not the only usability improvements we implemented during this sprint. Now the Partitioner offers more useful information about file-systems that need to be unmounted in advance and presents a more sensible initial state for the collapsable branches in its tables. YaST Network permits to tweak the virt bridge interface during manual installation and reports AutoYaST errors more nicely. Last but not least in the usability field, we improved how long texts are managed and presented in most YaST pop-up dialogs.

If you are still not impressed with all the new things this sprint brought, we can give you a sneak peak on something we have been preparing lately to give power-users more… er… power. ;-) As you all know, YaST is already a pretty advanced installer offering many options. And it’s very configurable so it can be tweaked to behave differently depending on the distribution, the product or the system role selected by the user. But believe it or not, we still face situations in which we would like to configure the installer even more during its execution to overcome some obstacle found in a very special scenario or just for debugging purposes. How do we plan to do it? Meet the new YaST installation console, available through the even newer installer configuration screen!

While we dive into the beta phase of openSUSE Leap 15.3 and SLE-15-SP3, the YaST Team will focus during the next weeks in fixing the bugs found by the testers of those upcoming distributions, which implies we cannot give you a fixed date for the next development report, but it will be for sure during March. Meanwhile, stay tuned and do not hesitate to report any significant bug you can find in YaST or in openSUSE in general. See you soon(ish)!

The call for papers for the openSUSE Virtual Conference is open!

The call for papers is open until May 4. This leaves a little more than 60 days to submit a proposal. The dates of the conference are scheduled for June 18 - 20. Registration for the conference has also begun.

Presentations can be submitted for the following length of time:

• Lightning Talks (15 mins)
• Normal Talk (30 mins)
• Long Talk (45 mins)
• Workshop (1 hour)

The following tracks are listed for the conference:

• Cloud and Containers
• Community
• Embedded Systems and Edge Computing
• New Technologies
• Open Source
• openSUSE

The conference already has two sponsors with Fedora and SUSE. Companies interested in sponsoring the event can view the sponsorship prospectus on the project’s wiki page.

Volunteers who would like to help the Program Committee and/or the Organizing Team can email ddemaio@opensuse.org.

Whenever technology and art meet in a very useful product, I can’t help but get excited and think about the applications of where a thing can be used. Instructables, yet again provides another incredible idea for something you can build as a life enhancement. I find the notion of combining a chalk board and a … Continue reading LCD Chalkboard Smart Sign, Raspberry Pi Powered →