Dear Tumbleweed users and hackers,

Week 5 – 5 snapshots. I hope nobody expects that we keep up the ‘week number == number of snapshots’, or I’ll be in deep trouble very soon. Looking at the staging dashboard it seems like the vacation period is definitively over: almost all stagings are full, but as not too many submitted things have proven to be broken it makes the stagings still manageable. It gets really difficult if we end up with a lot of breakage in the Stagings, then need to chase fixes.

The five delivered snapshots (0128, 0130, 0131, 0201, and 0202) brought you these changes:

• Polkit with fix for pwnkit (CVE-2021-4034)
• Switched default Ruby version to Ruby 3.1
• Dropped Ruby 2.7 and Ruby 3.0 (including all rubyx.y-rubygem-* packages)
• Mozilla Firefox 96.0.3
• git 2.35.1
• Linux kernel 5.16.4
• 389-ds 2.0.14
• Wireplumber 0.4.7
• pipewire 0.3.44

As already mentioned, the staging projects are mostly filled. The largest changes being integrated are:

• Linux kernel 5.16.5: fix for cifs crash, boo#1195360; full drm switch will follow later
• KDE Gear 21.12.2
• systemd: drop SUSE specific sysv support. Generic, upstream based sysv support remains in place. See original announcement at Factory mailinglist
• KDE Plasma 5.24 (currently beta is staged, release scheduled for Feb 8th)
• Lua 5.4.4
• rpm will no longer pull glibc-locale, but only glibc-locale-base, See this discussion
• glibc 2.35
• Python 3.6 interpreter will be removed (We have roughly 100 python36-FOO packages left)
• Python 3.10 as the distro default interpreter (a bit down the line)
• GCC 12 introduction has started to be as ready as possible for when the upstream release happens.

This week openSUSE Tumbleweed had a steady pace of snapshots with four releases users could #zypper dup their system into, which brought updates for an Internet Relay Chat client and a new default version of Ruby .

Version Control package git updated in snapshot 20220201. The 2.35.1 version of git now shows the number of stash entries with --show-stash like the normal output does. The color palette used by git grep has been updated to match that of GNU grep. The Mozilla Firefox 96.0.3 update fixed an issue that allowed unexpected data to be submitted in some of the search telemetry. Google’s data interchange format protobuf 3.19.4 fixed data loss bugs occurring when the number of optional fields in a message is an exact multiple of 32; this affected both Ruby and php in the package. Other packages to update in the snapshot were yast 4.4.43, python-fsspec 2022.1.0, suse-module-tools 16.0.19), and yast2-network 4.4.35, which transitioned to inclusive naming for asymmetric communication.

The IRC client hexchat was the single package updated in snapshot 20220131. The 2.16.0 version of hexchat updated the network list and included Libera.Chat as the default. The chat client also fixed miscellaneous parsing issues and added support for strikethrough formatting.

The 20220130 snapshot updated pipewire 0.3.44; this audio and video package changed some properties that make it possible to configure buffer sizes for larger than 8192, which is what JACK applications have as a hardcoded limit. The package also made it possible to run a minimal PipeWire server without a session manager, enough to run JACK clients. The default Ruby was switched to version 3.1. The version brings improved debugging performance, supports remote debugging and merges YJIT, which is a new in-process JIT compiler developed by Shopify. Salt 3004 arrived in the snapshot and offers new features. New modules for a transactional systems, like MicroOS, present challenges, yet salt 3004 supports atomicity-type systems via two new modules, transactional_update and rebootmgr, and a new executor transactional_update; the modules will help to treat the transactional system transparently. The glib2 2.70.3 update fixed a potential data loss due to missing fsync when saving files on btrfs. Other packages to update in the snapshot were snapper 0.9.1, libstorage-ng 4.4.78, bolt 0.9.2, freeipmi 1.6.9 and more.

Snapshot 20220128 also had an updated of libstorage-ng; the 4.4.77 version provided translations for the Brazilian Portuguese language. There was also another protobuf update that arrived at the beginning of the week; the 3.19.3 version improved parsing performance and aligned dependency handling best practices for building the package. Network and hardware utility package ethtool 5.16 added a couple new features like the use of memory maps for module EEPROM parsing and fixed a dumping of a FEC mode shown with --show-fec. The sendmail 8.17.1 package addressed several potential memory leaks and other similar problems that relate to error handling. PipeWire’s policy manager package wireplumber 0.4.7 fixed a regression that caused the selection of the default audio sources to be delayed and fixed a regression affecting the echo-cancellation pipewire module. Several YaST and RubyGem packages were also updated in the snapshot.

This weekend I am going to give a talk about sudo in the security track of FOSDEM. I will talk a few words about logging at each major point I mention, but I cannot go into too much detail there. So, consider this blog both as a teaser and an extension to my FOSDEM talk. You will learn how to work with JSON formatted logs in syslog-ng and also about new sudo features along the way. You will also learn about JSON logging in sudo, chroot support, logging sub-commands, and how to work with these logs in syslog-ng.

Read the rest of my blog at https://www.syslog-ng.com/community/b/blog/posts/working-with-json-logs-from-sudo-in-syslog-ng

Balázs Scheidler, founder of the syslog-ng project, started a new blog where he details why and how he started to work on syslog-ng even more actively. He also asks for your feedback!

“syslog-ng has been around for decades: I started coding the first version of syslog-ng in September 1998, circa 24 years ago. The adoption of syslog-ng skyrocketed soon after that: people installed it in place of the traditional syslogd across the globe. It was packaged for Debian, Gentoo, SUSE and even commercial UNIXes. It became a default logging daemon in some of these Linux distributions. Commercial products started embedding it as a system component. Over the years however I feel that syslog-ng has become a trusted piece of infrastructure, few people really care about. I set out to change that.”

Read the rest of the blog at https://syslog-ng-future.blog/syslog-ng-relaunch/

Many software teams struggle with ever growing cost of change, and technical debt that risks overwhelming them. 

It’s always interesting to talk with folks and understand, how the system and incentives created this state. 

Often I hear from software engineers that management doesn’t give them permission for (or doesn’t prioritise) work such as tidying, refactoring, testing, observability.

Blaming management in this way may be accurate in many situations (they are indeed probably accountable for the system that created this outcome). However, the problem with blame is that it tends to short-circuit further thinking. How could the system be improved with the influence and control you do have, perhaps with minimal authority.

But what about from the management side? I often hear from engineering and product managers that they’re unaware, or learn too late, that folks were accumulating debt. It becomes visible when teams are no longer able to achieve goals.  

Management has a bad reputation in the tech community. I’ve been very fortunate to work almost exclusively with managers who genuinely care deeply about the people and teams they support; who want what’s best for them in the long term.

And yet, it’s still common, with the best of intentions, to create systems that result in unsustainable software development, and lots of technical debt. 

How does this happen? 

The risks are not very visible. If managers were given the option of twice as much this month, in exchange for nothing for the next 6 months, they probably wouldn’t take it (perverse incentives like annual bonuses notwithstanding). Would that it were so simple. 

The decks are stacked against sustainability. It requires active effort from managers to combat the natural incentives.

Here’s three practical ways you can help as a manager.

1. Converse; don’t Coerce
2. Encourage Healthy Habits
3. Celebrate Sustainability

Converse; don’t Coerce

Get Curious

People will always want more than you’re able to achieve. Meaning we’re often starting from a position of saying no to lots of things that are very valuable; it’s faster to identify opportunities than it is to win them.

Most people don’t want to give bad news. Most people don’t want to hear bad news.  

This sets us up for miscommunication. 

<Manager> we need to do X this week
<Maker> Ok [unsaid: I’m going to risk a production outage by skipping testing]

If sufficient trust exists then it’s possible the risk will be vocalised, but the manager has not invited this feedback. Nor have they provided enough information for the maker to form their own opinion on the merits of the risk. 

It’s an instruction. There’s no curiosity as to what the impact or tradeoffs are, which shuts off thinking. 

It encourages risks. Some might infer an unsaid “…whatever it takes”. This could lead to taking risks such as skipping normal safety, or working long hours

It’s informationless. It’s a blanket “we need”. It doesn’t say what the value or tolerable costs are. The recipient has no information to make good judgements themselves with.

Things get a little better with even the slightest bit of curiosity.

<Manager> can we do X this week? 
<Maker> I think so [unsaid: cutting corners]
* next week *
<Manager> can we do Y this week?
<Maker> I think so [unsaid: that means they’ve decided not to clean up the debt from X]

At least the manager is now making it clear that there’s some degree of choice, although the power dynamic might make the choice seem illusionary. 

It’s a closed question. The manager’s likely to get yes or no answers. They’re not showing curiosity about the consequences of the team making X or Y happen. 

The manager is still asking the team to do things. Having to ask a team to do something is often a sign of a bug in the organisation. An organisational smell.

What’s stopping the team self-organising to the most important work? What information were the team missing to help them spot that X&Y were more important? What skills or perspectives are they missing to be able to make the best choices? 

Use Open Questions

Things improve further if we ask open questions:

<Manager> what would we drop if we tried to do X this week? 
<Maker> well we were planning on implementing the actions from last week’s post mortem, if we postponed those we might be able to do X.

or

<Manager> on a scale of 1-5, how risky would it be to release X this week? 
<Maker> Hmm, probably a 4, we’d not have any time to test or do a canary deployment so we’d lose our usual safety nets

Here the manager has asked open questions, and solicited information that might help make better decisions. Even if the manager then asks the maker to do the same thing, the risks have at least been taken more intentionally.

Prefer information over instructions

What if we didn’t ask the team to do X at all?

<Manager> I’ve learned that we could close a $n deal if we can ship X this week. 
<Maker> Hey that’s more than the total cost savings from what we were working on, let’s do X instead.

or

<Manager> I’ve learned that we could close a $n deal if we can ship X this week. 
<Maker> Hmm, but if we rush we risk breaking the service. Last time this cost us $10*n

However, this is somewhat optimistic. Even with all the information, people often have recency bias and eagerness to please. The power dynamic between manager and maker often exacerbates this.

Incentives conspire to eliminate slack time that would be used to keep development sustainable. 

Combining Curiosity and Information

<Manager> I’ve learned that we could close a $n deal if we can ship X this week. 
<Maker> Hmm, that sounds like a lot, I can get it done
<Manager> How risky is it on a scale of 1-5?
<Maker> Probably a 1, we’ve still got time to test it carefully. 
<Manager> What things are we dropping that we’d otherwise be doing?
<Maker> Oh we were going to refactor Y as changes in that area are slow
<Manager> Oh I thought Y was done months ago
<Maker> We shipped it months ago but have since noticed the design trips us up and we never have time to fix it with all these urgent opportunities.
<Manager> How much time has it cost us? 
<Maker> More than it takes to ship X just this month

Here the manager and maker have built a much richer understanding of the situation and tradeoffs. They are much better placed to make a decision than if the maker had simply been asked to ship X.

Encourage Healthy Habits

Team habits can help people escape the trap of needing permission from unsupportive or oblivious management. You will probably be unsupportive or oblivious at some point. Unintentionally coercing people is so easy. 

You can counter this by encouraging your team to adopt habits that will resist your efforts to coerce them into doing the wrong thing.

If your team practices TDD then you’d have to break a strong habit to encourage people to release a feature without tests.

If your team habitually drops everything to bring the build time down every time it creeps above 5 minutes, then they’re more likely to do the same even if you’ve asked them to deliver a feature.

If your team habitually prioritises work based on cost of delay, then they’ll likely ask you questions to find out the value before jumping on it. Even if you have omitted the information in your request.

Habits are hard to break. This can be a good thing. The right habits can add resistance to the forces that conspire to create creeping loss of sustainability. 

Celebrate Sustainability

If you publicly appreciate internal improvements you will signal for more.

If your only questions about the work are inquiries about when it will be finished, you’ll incentivise unsustainable working.

If your promo process only recognises features and customer impact, you’ll discourage sustainability.

Do you celebrate with the team as much when they halve their deploy time, as when the ship that flagship feature?

Do you thank folks for taking extra days to refactor and clean up the code?

Do you ask “how much more could we simplify it?” or “when will we be done?”

Do you ask “what if tried doing less?” or “how can we do more?”

The post Supporting Sustainability appeared first on Benji's Blog.

I’ve worked in and with teams who would identify as agile for many years. I’ve written about how I think the most interesting part of the agile manifesto is the “uncovering better ways” mindset. 

With this in mind, I’ve been pondering how the principles in the agile manifesto have aged. Where do (and don’t) I share the same principles. 

Given the “better ways” of developing software we’ve uncovered, can we “turn up the dials” on the principles as well as the ways of working? 

Principles tend to stand the test of time better than specifics. The agile manifesto still reads as an aspirational document today, but I think there’s room for improvement.  

Here’s my take on things I’d tweak in each principle; hopefully staying true to the values. 

Bettering Ourselves

Building working software is a powerful tool to achieve our ends. However, I wouldn’t consider it the highest priority of a team. If we can achieve our goals without software (which can be a liability) that’s even better. 

Moreover, if the software we’re asked to build is harmful for humanity, or counter to our organisational/personal values; avoiding that comes before satisfying the customer. The negative impact software can have on society is increasingly evident as more of our society is controlled by software.

“Bettering ourselves” (optimise for learning) is at the heart of agile to me. To borrow from Captain Picard, I’d state our highest priority as:

Learning we’re Wrong

We’re not passively waiting for requirements. We can take more ownership over our goals and understand customer needs ourselves. We’ve shifted from requirements to forming our own hypotheses of what customers need.

It’s not that requirements change, it’s our understanding that improves. We learn how we were wrong and adapt our goals in response.

We don’t need to build for a customer-proxy (stakeholder who wants the software). We’re can build products for people; they are our customers.  By meeting customer needs, we build a competitive advantage for ourselves.

Continuous Delivery

The only thing worth changing in the continuous delivery principle, is that our tooling and platforms are so much better now than 20 years ago. We can deliver considerably faster and smaller.

A team can feasibly ship multiple times a day—given a good continuous delivery pipeline, reliable & fast tests, production safety net from canary deploys, and production observability. We’re no longer having to burn CDs with software builds.

All the Brilliant People

I’d replace project with product; due to the temporary-team fixed time/budget/requirements connotations of project.

I think longer lived product teams are more effective. I appreciate this won’t be for folks working in a project/consultancy context but I avoid those ;) 

I’d also expand to “all the brilliant people” as per Woody Zuill’s description of mob programming. Get everyone needed to achieve the goals together into the team, collaborating together every day. Minimising dependencies and handoffs.

Product Teams over Individuals on Projects

As per above, I prefer sustained investment in stable product teams over the project model.

Communication Quality over Efficiency

This is the only principle I feel like I’m watering down rather than turning up.

I think face to face conversation is still the highest bandwidth communication method. However, face to face communication is not always feasible for practical & inclusion reasons. Reasons such as geographic location, neurodiversity, family commitments, carbon footprints, and global pandemics! 

If face to face communication is infeasible then it’s not the most effective method of communication; even if it would be the highest bandwidth method.

I think the general principle is it’s better to trade off efficiency for quality of communication. Be willing to sacrifice time for better communication. You’ll save time in the long run. Prefer the highest bandwidth communication you can enable, even if it feels inefficient.

Results are the primary measure of progress

I don’t see working software as the primary measure of progress. We can ship oodles of working software every day and benefit nobody.

How are people’s lives enriched by our toil? How are our organisational goals furthered by our software? How is society better?

Have we achieved what we set out to? What have we learned from our experiments?

The less software needed the better!

Sustainability

I’d make the call for sustainbility more imperative. We don’t rely on static processes to keep development sustainable. It requires active effort and adaptation to combat the natural incentives in play.

We don’t go fast now at the expense of tomorrow. We strive to keep the cost of change curve low. 

Technical Excellence

I find myself avoiding the words agile and agility since “agile” has become so semantically diffused it can create confusion.

Simplicity

The principle of simplicity is timeless.

Diverse Teams

I’d add diversity to the description of teams that produce the best results. Self-organising teams with a monoculture are not going to produce the best ideas; there’ll be shared blind spots.

I think it can also be useful to expound on some of the things teams need to self-organise effectively.

Double-loop Learning

I’d just add adjusting goals, in addition to tuning team behaviours. The most effective teams benefit from double loop learning. Learning-through-doing that our goals are wrong, or our assumptions when choosing our goals were wrong. 

Your Team’s Principles

How do your principles differ? I’ve only thought about things I’d tweak from the manifesto principles above, not what I’d add. What would you add?

The post Pondering Agile Principles appeared first on Benji's Blog.

Introduction

mdBook allows you to create book from markdown files. It’s pretty much alike Gitbook but implemented in Rust. However, unlike Gitbook that supports using calibre for generating PDF, for a long time, mdBook doesn’t support generating PDF files natively, and supporting that is also not in their roadmap. Existing plugins (backends) such as mdbook-latex that utilize Tectonic as well as pandoc solutions will generate a PDF page that doesn’t unify with the existing mdBook generated HTML version. Considering these facts, I created a mdBook backend named mdbook-pdf for generating PDF based on headless chrome and Chrome DevTools Protocol Page.printToPDF.

mdbook-pdf depends on Google Chrome / Microsoft Edge / Chromium. The generated page are pretty much alike the one you manually print to PDF in your browser by opening print.html or executing google-chrome-stable --headless --print-to-pdf=output.pdf file:///path/to/print.html, but with customization of PDF paper orientation, scale of the webpage rendering, paper width and height, page margins, generated PDF page ranges, whether to display header and footer as well as customize their formats, and more, as well as automation. It supports all the platform where Google Chrome / Microsoft Edge / Chromium would work. You can check samples of the generated PDF files in the Artifacts here (The Rust book collections generated in x86_64 Windows, macOS as well as Linux).

Installation & Usage

Since it’s a plugin (backend) for mdBook, first of all you should ensure that mdbook is available.

If your machine’s architecture is x86_64, or you are using Linux for ARM64, check the successful build GitHub Actions workflows, click into the latest one, and then you can get a binary from the Artifacts (including Windows, Linux, macOS).

Otherwise, make sure the rust compiling environment is available, execute cargo install mdbook-pdf to compile and install.

If you want to compile the latest version, make sure the Rust build environment is available (cargo build). Then run git clone https://github.com/HollowMan6/mdbook-pdf.git, in the cloned folder, run cargo build --release , get the executable in target/release/, and put it in PATH.

For running, have Google Chrome / Chromium / Microsoft Edge available (installed at the default location, in PATH or binary location configured) as currently, automatically downloading Chromium binary isn’t available (will update once upstream fixes such support).

• On Windows 10 and above, the program can generate PDF normally without installing any additional software, because Microsoft Edge is the browser provided with Windows system. Of course, considering the support for the older versions of Windows without Edge, you can install Google Chrome on your computer.
• In MacOS, you need to install Google Chrome / Microsoft Edge or Chromium.
• In Linux, you can choose to install any of the Google Chrome / Chromium / Microsoft Edge browsers. It is recommended to install Chromium. The name of this software package in your Linux distribution is commonly chromium or chromium-browser (Note: for Ubuntu later than 18.04, you have to install chromium-browser through snap).

Make sure the following exists in your book.toml:

[output.html]

[output.pdf]

And also [output.html.print] is not disabled (it should be enabled by default, so don’t worry if the following lines doesn’t occur in you book.toml).

[output.html.print]
enable = true

A simplest book.toml is as follows:

[book]
title = "An Example"

[output.html]

[output.pdf]

Finally you can build your book and get the PDF file with mdbook build command, your PDF file will be available at book/pdf/output.pdf.

Configuration

Check book.toml and comments for details for the available configurations of [output.pdf].

Credits

This project relies on headless_chrome. Because the new version has not been released, and the default timeout is not friendly to PDF generation, I use my Fork version to publish mdbook-pdf-headless_chrome for expanding the relevant timeout to 300 seconds as a submodule of this project, thus enabling the project to be published on Crates.io as well.

Some Notes and Thoughts

mdBook supports adding alternative backend. When the mdbook build command is invoked, if the book.toml in the book folder has an [output.pdf] item in addition to the default [output.html] for generating the html web page, mdbook-pdf will be called, and the relevant book information and parameter configuration in JSON are passed to the standard input of the program. Relevant mdBook documentation can be found here.

A headless browser means that all the operations will be in the background without a graphical interface.

Before decided to use Chrome DevTools Protocol Page.printToPDF, I also tried wkhtmltopdf which is based on QT4 Webkit. Hovewer, wkhtmltopdf doesn’t seem to support CSS Printing @media Rule, which will make some extra components visible and printed in the PDF.

I’ve also tried directly making HTTP calls to the WebDriver in python based on W3C WebDriver Protocol Print Page, as well as using selenium for calling Chrome DevTools Protocol Page.printToPDF in Python. All those methods are not robust for large pages with the errors as follows for just the same reason for the original upstream headless_chrome: the default timeout is 10 seconds, which is not friendly to large page PDF generation.

timeout: Timed out receiving message from renderer: 10.000

selenium.common.exceptions.WebDriverException: Message: unknown error: session deleted because of page crash
from unknown error: cannot determine loading status
from tab crashed

At present, I have tested that Firefox does not support using headless_chrome for PDF generation, and the Safari browser even does not support the W3C WebDriver Protocol Print Page, let alone Chrome DevTools Protocol.

I’ve noticed that for some book, by using this backend, when click on some links that link inside the book, a html page that points to the original generated HTML storing path of the book will be opened, just as the issue mentioned here. I guess for those “internal” links inside the book, work should be done in the mdbook side for print.html referring here so that all the links linked “internally” would jump inside the generated print.html, as all the contents should already be on the print.html, there shouldn’t be any hyperlinks that jump to other html files in the book. By resolving in this way, the generated PDF would also jump internally instead of opening a browser that won’t connect to anything. I have already created a PR for this, hope it will get merged soon.

In addition, as I found that special characters such as : are very likely to appear in the title of the book, which will cause the generation of the related PDF file to fail, so the file name does not use the form of <book name>.pdf but output.pdf

Hope you enjoy it.

Dear Tumbleweed users and hackers,

The week has passed without any major hiccups, which also shows in the number of Tumbleweed snapshots released during this week. Not the highest count ever achieved, but we are at a solid 6 snapshots (0121.0126), with the next one already in QA.

The major changes in those 6 snapshots were:

• systemd 249.9
• Lots of YaST changes (mostly under the hood, some UI changes in the installer)
• Mozilla Firefox 96.0.2
• Samba 4.15.3 & 4.15.4, including a rather large reorganisation of the library packages (i.e. multiple libs combinaed into samba-client-libs
• Virtualbox 6.1.32
• Bash 5.1.16
• Linux kernel 5.16.2
• Switch the default Network interface manager from wicked to NetworkManager: so far this was only done for graphical installations, but newly NetworkManager is also the default on server/console-only installs. With nmtui it is rather comfortable to configure it. Upgraders do not (yet) get migrated to NetworkManager, but stay on their working wicked config. Of course wicked is still available in the repos

Thins being worked on to reach you in the future include:

• Linux kernel 5.16.3
• Polkit with fix for pwnkit (Snapshot 0127(: the fix is also already in the Tumbleweed update channel. Make sure to get this update soon
• Ruby 3.1, incl switch of default Ruby version to 3.1
• Removal of Ruby 2.7 and Ruby 3.0 (together with the switch to Ruby 3.1)
• KDE Plasma 5.24 (currently beta is staged and being tested)
• Python 3.6 interpreter will be removed (We have roughly 100 python36-FOO packages left)
• Python 3.10 as the distro default interpreter (a bit down the line)
• GCC 12 introduction has started to be as ready as possible for when the upstream release happens.