MemberAdd a network printer through Yast under openSUSE
Digest of YaST Development Sprints 119, 120 & 121
YaST development never stops. But we have to admit we have not kept our readers as informed as usual about the activities of the YaST team, other than our blog post about Hack Week. We had to adapt the length and focus of some sprints before and after Hack Week. That, together with Easter season in Europe and some extra vacations, affected our good publishing habits. On the bright side, we have tons of topics for you, let’s do a quick recap.
- Reduction of the memory consumption during installation.
- New option to enable installation in systems with small RAM.
- Improvements in the NetworkManager support.
- Polishing of the upcoming releases, especially AutoYaST and hardware enablement.
- A new
extendparameter inlinuxrcto help openQA. - More consistent and polished LibYUI development.
- Research and open discussion about the current state and future of:
- YaST Firstboot,
- YaST Users,
- the installation workflow.
So let’s go by parts. As you may know, libzypp was recently updated in all SLE and openSUSE
distributions to bring some cool new features. Unfortunately that came with a small increase in
memory consumption. That was enough to exceed the current installation requirements, so we had to
find some way to save memory in the installer. We adjusted several things, especially the installer
self-update mechanism. See this pull request
to know how we managed to fit again into the requirements. As a nice side effect, we improved the
handling of the memsample script we use to track memory usage during installation.
Talking about the memory consumption of the installation process, we also added a cool feature to
linuxrc and YaST that makes possible to install (open)SUSE in systems with an small amount of
memory. Check the new zram parameters in the linuxrc
documentation and see the description of this pull
request if you are interested in the details.
Another area that received quite some love is the support for configuring NetworkManager during the installation process. For SLE-15-SP3 and Leap 15.3 that includes better DNS settings, support for bridge and bonding configuration and improved AutoYaST integration. For Tumbleweed it also includes displaying the corresponding details in the installer’s summary screen.
We also invested quite some time polishing the upcoming releases of openSUSE Leap 15.3 and SLES-15-SP3. Especially improving the handling of AutoYaST profiles, extending the support for some storage technologies like NVMe and adjusting the boot loader configuration for a wide range of hardware.
On the more technical side of things, we also added a new extend
parameter to linuxrc (which now allows a smooth
integration of the libyui-rest-api plugin in openQA) and we unified the repositories of LibYUI (which simplifies maintenance and future contributions).
While doing all that, we also found time to think about the future of YaST. We did some extensive research on the current state of three areas we would like to improve in the mid term:
-
YaST Firstboot. Check this Github issue (and all the related issues linked from it) describing several aspects of the current state and also ideas about improving its look&feel and making it a more useful tool.
-
The current installation process. Again, we are using Github issues to discuss how to make it shorter and more understandable. As a starting point, check this issue that contains an interesting conversation and also links to several other related issues.
-
YaST Users. We are considering to refactor this module to improve the management of local users and to reduce the risk introduced by its current complexity. As a first step, we created a new repository that, so far, contains several documents describing the status quo.
As you can see, we may have been a bit absent but definitely we have not been idle. And the best news is that we are back to our usual biweely schedule, so we will have more to share soon. Meanwhile stay safe and fun!
llunakThe effect of CPU, link-time (LTO) and profile-guided (PGO) optimizations on the compiler itself
In other words, how much faster will a compiler be after it's been built with various optimizations?
Given the recent Clang12 release, I've decided to update my local build of Clang11 that I've been using for building LibreOffice. I switched to using my own Clang build instead of openSUSE packages somewhen in the past because it was faster. I've meanwhile forgot how much faster :), and openSUSE packages now build with LTO, so I've built Clang12 in several different ways to test the effect and this is it:
The file compiled is LO Calc's document.cxx, a fairly large source file, in a debug LO build. The compilation of the file is always the same, the only thing that differs is the compiler used and whether LO's PCH support is enabled. And the items are:
- Base - A release build of Clang12, with (more or less) the default options.
- CPU - As above, with -march=native -mtune=native added.
- LTO - As above, with link-time optimization used. Building Clang this way takes longer.
- LTO+PGO - As above, also with profile-guided optimization used. Building Clang this way takes even longer, as it needs two extra Clang builds to collect the PGO data.
- Base PCH - As Base, and the file is built with PCH used.
- LTO+PGO PCH - As LTO+PGO, again with PCH used.
Or, if you want this as numbers, then with Base being 100%, CPU is 85%, LTO is 78%, LTO+PGO is 59%, Base PCH is 37% and LTO+PGO PCH is 25%. Not bad.
Mind you, this is just for one randomly selected file. YMMV. For the build from the video from the last time, the original time of 4m39s with Clang11 LTO PCH goes down to 3m31s for Clang12 LTO+PGO PCH, which is 76%, which is consistent with the LTO->LTO+PGO change above.
openSUSE Tumbleweed – Review of the week 2021/15
Dear Tumbleweed users and hackers,
After I left you and Tumbleweed in the capable hands of Richard for two weeks, it is good to be back. The week has seen a slightly lower count of published snapshots, but only because openQA was nice enough to find bugs that we did not you having to fight with. So, we only released two snapshots (0408 and 0414). As usual, the large gap means a few snapshots were tested in between, and things accumulated.
As a result, we managed to deliver these updates to the users:
- openSSL 1.1.1k
- systemd 246.13
- libvirt 7.2.0
- KDE frameworks 5.81.0
- KDE Plasma 5.21.4
- GNOME 40.0
- GStreamer 1.18.4
- Linux kernel 5.11.12
- Ruby 2.7.3 and Ruby 3.0.1
Staging projects are busy, but luckily with a bit of space to actually stage new requests. The main changes currently being tested and coming to you in the future are:
- LXQt 0.17.0
- Python 3.9 modules: besides python36-FOO and python38-FOO, we are testing to also shop python39-FOO modules; we already have the interpreter after all. Python 3.8 will remain the default for now. Building in snapshot 0415
- Linux kernel 5.11.14+
- LibreOffice 7.1.2.2
- UsrMerge is progressing well, thanks to Ludwig for his continued work here
- GCC 10.3.0
- GCC 11 as the default compiler
GNOME 40, KDE Frameworks, Plasma Update in Tumbleweed
Two openSUSE Tumbleweed snapshots were released since last week’s blog.
The snapshots brought the much anticipated GNOME 40 as well as an update of KDE Frameworks 5.81.0, Plasma 5.21.4 and several other packages.
The 20210414 snapshots was a monster; the amount of packages updated in the snapshot was ginormous. The update to GNOME 40 brought some significant changes to the desktop environment. New visual changes with rounded corners, and gestures like a three-finger swipe to move between workspaces were among the improvements in the release. The app launcher is more customizable and more intuitive to navigate with a mouse. Another desktop environment that was updated in the snapshot was Plasma 5.21.4, which had color scheme fixes and a fix for a broken keyboard configurations with single layout on Wayland. The release also set the preferred aspect ratio to “21:9” over “64:27” with KScreen. KDE Frameworks 5.81.0 added high-brightness and low-brightness Breeze Icons and the user interface builder Kirigami fixed a potential crash in the SizeGroup. Even Xfce had in update in the snapshot; this update in the xfce4-settings 4.16.1 package fixed scaling and updated translations. Dependencies were update in the upgrade to nodejs15 15.14. There was a minor fix for the cups printing package and xterm 367 updated some patches and improved responsiveness of the terminal. Linux Kernel 5.11.12 arrived in the snapshot and had several Advanced Linux Sound Architecture fixes and a commit for a nosy driver with Common Vulnerabilities and Exposures (CVE)2021-3483. Both ruby2.7 and ruby3.0 received minor updates to fix an XML vulnerability and GStreamer 1.18.4 fixed mpeg-2 video handling and a memory leak. Several YaST packages also had updates.
A major version update of audacity 3.0.0 arrived in snapshot 20210408. The format to save Audacity projects was changed and a new analyzer called Label Sounds can label sounds and silences for more effective use of the application. Less than a handful of CVEs were updated in curl 7.76.0; the command line tool strips credentials from the auto-referer header field and adds support to read and store the referrer header. An update of systemd 246.13 had some changes to handle large packets more gracefully and rubygem-rubocop 1.12.1 had an enormous amount of fixes jumping from version 1.8.1. Another package that received a large amount of updates was vim 8.2.2725; there were fixes for a memory leak when compiling and a fix for hangs with the terminal when resized. The xf86-input-libinput package moved from version 0.30.0 to 1.0.0 and its biggest change was the change to an MIT Licence. Other packages updated in the snapshot were bind 9.16.12, fwupd 1.5.8 and openssl 1.1.1k, which fixed CVE-2021-3450 that had a problem with verifying a certificate chain when using a certain flag.
A Message from the openSUSE Board
(This message was originally published on the mailing list on April 2, 2021)
We, the members of the openSUSE Board, strongly value the openSUSE Code of Conduct and Guiding Principles:
Inclusion is a fundamental pillar of our community and the broader free software and open source communities that we are part of, are connected with, and value.
We firmly stand against sexism, racism,… and strive to keep our communities open, welcoming, and safe for everyone to join.
As a board, we also believe that these principles that apply to our openSUSE communities shall also apply to the events and groups that we partner with and sponsor.
We are reassessing our sponsorships in that light.
In accordance with this statement, we are discontinuing sponsorship of all events and organizations affiliated with the Free Software Foundation until further notice.
Axel, Gerald, Gertjan, Neal, Simon, Syds, Vinz
Don’t hire top talent; hire for weaknesses.
Instead of starting from “how do we hire top talent?”, start from “what are our weaknesses?”
Why are you hiring? Are you hiring to do more, or are you hiring to achieve more?
Design your hiring process to find the right people to strengthen your teams’ weaknesses, rather than trying to find the best people.
Instead of “how can we find the smartest people?” think about “how can we find people who will make our team stronger?”
Often the language used by those hiring betrays their view of people as resources. Or, to use its current popular disguise: “talent”.
“We hire top talent” “the candidate didn’t meet our bar”, “our hiring funnel selects for the best”. “we hire smart people and get out of their way”. We design “fair tests” that are an “objective assessment” of how closely people match our preconceptions of good.
The starting point for the talent mindset is that we want to hire the smartest people in the “talent pool”. If only we can hire all the smartest people, that will give us a competitive advantage!
If you focus on hiring brilliant people, and manage to find people who are slightly smarter on average than your competitors, will you win? Achievements in tech seldom stem solely from the brilliance of any one individual. Successes don’t have a single root cause any more than failures do.
We’re dealing with such complex systems; teams that can capture and combine the brilliance of several people will win.
With the right conditions a team can be smarter than any individual. With the wrong conditions a team can be disastrously wrong; suffering from over confidence and groupthink, or infighting and undermining each other. Hiring the right people to help create the right conditions in the team gives us a better chance of winning than hiring the smartest people.
| Talent Mindset | Weaknesses Mindset |
| Find top Talent | Find skills that unlock our potential |
| Grow Team | Transform Team |
| Help teams do more things | Help teams achieve greater things |
| People who can do what we’re doing | People can do things we can’t do |
| Hire the best person | Hire the person who’s best for the team |
| People who match our biased idea of good | People who have what we’re missing |
| Fair tests & Objective assessment | Equal opportunity to demonstrate what they’d add to our team |
| Consistent process | Choose your own adventure |
| Hire the most experienced/skilled candidate | Hire the person who’ll have the greatest impact on the team’s ability. |
| Number of candidates & Conversion rate | How fast can we move for the right candidate? |
| Centralised Process & Bureaucracy | Teams choose their own people |
| Grading candidates | Collaborating with candidates |
| Prejudging what a good candidate looks like | Reflecting on our team’s weaknesses |
| Fungibility | Suitability |
| Smart people | People who make the team smarter |
| Intelligence | Amplifying others |
| Culture Fit | Missing Perspectives |
| People who’ve accomplished great things | People who’ll unblock our greatness |
| Exceptional individuals. | People we can grow and who will grow us |
| What didn’t the candidate demonstrate against checklist | What would the candidate add to our team |
Talent-oriented hiring
If we start out with the intent to find the “best people” it will shape our entire process.
We write down our prejudices about what good looks like in job descriptions. We design a series of obstacles^Winterviews to filter out candidates who don’t match these preconceptions. Those who successfully run the gauntlet are rewarded with an offer, then we figure out how to best put them to use.
Hiring processes are centralised to maximise efficiency & throughput. We look at KPIs around the number of candidates at each stage in the funnel, conversion rates.
Interviewing gets shared out around teams like a tax that everyone pays into. Everyone is expected to interview for the wider organisation.
Hiring committees are formed and processes are standardised. We try to ensure that every candidate is assessed as fairly as possible, against consistent criteria.
We pat ourselves on the back about how we only hire the top 1% of applicants to our funnel. We’re hiring “top talent” and working here is a privilege. We’re the best of the best.
Weaknesses-oriented hiring
There’s another approach. Instead of starting from our idea of talent and the strengths we’re looking for, start from our weaknesses. What’s missing in our team that could help us achieve more?
Maybe we have a team of all seniors, frequently stuck in analysis. We need some fresh perspectives and bias for action.
Maybe we are suffering from groupthink and need someone with a different background and new perspectives. Someone who can help generate some healthy debate?
Maybe we have all the technical skills we need but nobody is skilled at facilitating discussions. We struggle to get the best out of the team.
Perhaps we’re all fearful of a scaling challenge to come. We could use someone experienced who can lend the team some courage to meet the challenge.
Maybe those in the existing team specialise in frontend tech, and we’ve realised we need to build and run a data service. We could learn to do it, but bringing someone in with existing knowledge will help us learn faster.
Maybe we are all software engineers, but are spending most of our time diagnosing and operating production systems. Let’s add an SRE in the team.
Maybe we don’t even know what our weaknesses are—until we experience collaboration with the right person who shows us how to unlock our potential.
Identify your weaknesses. Use them to draft role descriptions and design your interview processes.
Design your interviews to assess what the candidate brings to your team. How do they reduce your weaknesses and what strengths would they add?
Leave space in the process to discover things people could bring to your team that you weren’t aware you needed.
A talent-oriented process would assess how the candidate stacks up against our definition of good. A weaknesses-oriented process involves collaborating with the candidate, to see whether (and how) they might make your team stronger.
If possible, have candidates join in with real work with the team. When this is not feasible for either side, design exercises that allow people on your team to collaborate with them.
Pair together on a problem. Not what many companies call paired interviews where it’s really an assessor watching you code under pressure. Instead, really work together to solve something. Help the candidate. Bounce ideas off each other. Share who’s actually doing the typing, as you would if you were pairing with a colleague. Don’t judge if they solved the same problems you solved; see what you can achieve together.
A weaknesses-oriented process might mean saying no to someone eminently qualified and highly skilled; because you have their skills well covered in the team already.
A weaknesses-oriented process might mean saying yes to someone inexperienced who’s good at asking the right questions. Someone whose feedback will help the experienced engineers in the team keep things simple and operable.
Why not both?
It’s often worth thinking about when something good is not appropriate. There are rarely “best practices”, only practices that have proven useful in a given context.
At scale I can see the need for the talent-oriented hiring approach in addition to weaknesses-oriented.
Exposing all of your teams’ variety of hiring needs to candidates may create too much confusion.
You may well want a mechanism to ensure some similarity. A mechanism to select for those who share the organisational values. To find those with enough common core skills to increase the chances that they can move from team to team. Indeed, long-lived and continuously funded teams are not a given in all organisations.
If you’re getting thousands of applications a day you’ll probably want a mechanism to improve signal to noise ratio for teams wishing to hire. Especially if you don’t want to use education results as a filter.
I suspect a lot of hiring dysfunction comes from people copying the (very visible) talent-oriented top-of-funnel hiring practices that big companies use. Copy-pasting as the entire hiring mechanism for their smallish team.
Start from reflecting on your weaknesses. Whose help could you use? Some of the practices from the talent-oriented approach may be useful, but don’t make them your starting point. Start from your weaknesses if you want strong teams.
The post Don’t hire top talent; hire for weaknesses. appeared first on Benji's Blog.
openSUSE Tumbleweed – Review of Weeks 2021/13 & 14
Dear Tumbleweed users and hackers,
Dominique has been enjoying a vacation these last two weeks and left Tumbleweed in my hands. Thanks to all who’ve helped out as I got to grips with holding the reins solo for the first time.
These two weeks also saw the long Easter weekend. That said, we still managed to release 5 snapshots (0325, 0329, 0330, 0401 and 0406) during this fortnight, with 0408 currently in testing and an 0409 likely to be checked in tonight.
The changes delivered these weeks included:
- SELinux 3.2 (now also used by default in MicroOS)
- transactional-update 3.3.4
- A large amount of YaST updates
- Mozilla Firefox 87.0
- git 2.31.1
- kernel 5.11.11
- Mesa 20.3.5 with a large number of fixes
- MicroOS GNOME Desktop reaching [BETA] quality
The future, near or far, will bring those updates:
- systemd v246.13 with cgroupsv2 enabled by default (Currently being tested in 0408)
- libvirt 7.2.0 (Currently being tested in 0408)
- GNOME 40 (Currently being needled, hopefully will be included in 0409)
- KDE Plasma 5.21.4
- LibreOffice 7.1.2.2
- nodejs 15.14.0
- gstreamer 1.18.4
- Further MicroOS GNOME Desktop improvements
- Python 3.9 modules: besides python36-FOO and python38-FOO, we are testing to also shop python39-FOO modules; we already have the interpreter after all. Python 3.8 will remain the default for now.
- UsrMerge is progressing well, thanks to Ludwig for his continued work here
- GCC 10.3.0
- GCC 11 as the default compiler
Have a lot of fun!
– Richard
Two Tumbleweed Snapshots Update Fetchmail, Mesa, More
A couple of openSUSE Tumbleweed snapshots were released since the beginning of the month.
The two snapshots updated more than 30 packages and the latest snapshot, 20210406, gave rolling release users an update of Mozilla Firefox 87; the new release had several fixes including a fix to the video controls, which now have visible focus styling. The video and audio controls are now keyboard navigable. Firefox also sets a useful initial focus in the Add-ons Manager. New features in the browser release include the “Highlight All” feature on the “Find in Page”, which now displays tick marks alongside the scrollbar that correspond to the location of matches found on that page; this is a great feature for those who do keyword searches. Mozilla updates in the snapshot were finished as Thunderbird updated to version 78.9.0. The bugfix update for the email client had some security fixes and a fix for fields that were unreadable in the Dark theme in the General preferences panel. The update of fetchmail 6.4.18 fixed the configuration parser in fetchmailconf, which had an effect in version 6.4.16 when --sslcertfile was added to the configuration dump. The new version of fetchmailconf –version now prints the Python version in use. The snapshot gave users the 5.11.11 Linux Kernel, which had some changes for btrfs and x86 KVM. Other packages updated in the snapshot included spamassassin 3.4.5, git 2.31.1 and attr 2.5.1, which fixed a libtool library versioning regression.
The 20210401 didn’t deliver any foolery but it did deliver some magic; ImageMagick 7.0.11.5 disables framework OpenCL by default. Use the environment variable MAGICK_OCL_DEVICE to turn it on or select the device to use. Mesa and Mesa-drivers 20.3.5 went on a bug-hunting expedition as the release was quite large and had a huge number of fixes. Radv and ACO dominated the changes for the release and a graphical glitch was fixed that has been around since version 18.0.5. The extensible text editor emacs 27.2 changed the behavior of the user option ‘resize-mini-frames’ and the user option ‘tramp-completion-reread-directory-timeout’ is now obsolete. QR-Code-generator dropped a patch in its 1.6.0 update nodejs15 15.12.0 addressed a dependency change needed for a stopgap with OpenSSL. Raw data file editor okteta 0.26.6, openexr 2.5.5, yast2-firewall 4.3.11 and yast2-firstboot 4.3.11 were among the other packages updated in the snapshot.