Also, I’ve sent two poster proposals for Wikimania 2024:
Towards a Very Small GLAM entities solution:
This proposal proposes an activity line for empowering very small GLAM entities with limited resources to preserve and document cultural heritage effectively. It comprises:
the development an open-source GLAM suite and
recommendations on affordable, reliable hardware.
The suite includes:
software such as unRAID OS with ZFS for data preservation and
Wikibase and packaged software services.
Also a preload of metadata for museology (ontologies and vocabularies) and a technical information collection in the form of linked open data and documents.
The proposal outlines the project’s timeline, funding sources, and physical and online community involvement.
and
Wikimedia LEADS a Learning Ecosystem and Ameliorating Data Space:
To create a free ecosystem and data-space for learning in the Wikimedia Movement. Ecosystem will extends the Movement with new classes of knowledge and addressing sustainability needs. With:
libraries of:
practices, modeled in Wikibase as Linked Open Data (LOD);
credentials, also modeled as LOD, based in ELM;
software extensions and services required for a working implementation in the Movement.
First will address the GLAM Wiki domain, producing incremental results ready to be adopted. This domain strongly intersects with the Wikimedia Movement.
Furthermore, the methodologies, tools and many of the specific contents will be applicable to any other knowledge areas.
We have coined the term Very Small GLAM to refer the community of very small GLAM institutions: private, public, formal or informal, etc. It has not a rigorous definition, but you can think in teams of less than 10 members and reduced budget. So we’ll drop the bombastic term of «Small GLAM SLAM».
About Wikimedia LEADS, this is a new line of work also based in Wikibase to develop a Wikimedia ecosystem of models for Essence practices and microcredentials. It has been proposed for an European Union grant so it has no funding yet. This initiative interesects with Very Small GLAM as both focuses first in contents for the GLAM Wiki domain, as project driver.
The SCaLE (The Southern California Linux Expo) community Linux event delivered an iconic experience with four days of open source training, exhibits, and general presentations. This year’s conference took place in Pasadena (Los Angeles) area.
This expo drew worldwide guests to discuss AI, Linux, security, embedded, IoT, and more. The Conference Chair, Mr. Ilan Rabinovitch, and Technical Committee Chairperson, Owen Delong paved the way for a smooth registration.
Ilan Rabinovitch
Conference Highlights
Fedora @ SCaLE 21x Linux Conference – Ready, Set, Go!
Justin Flory arranged and shipped hand-selected swag and marketing items to Brian Monroe. Items include: pens, stickers, commuter mugs, badge ribbons, badge lanyards, and more.
Furthermore, the ambassadors gathered up supplies for the conference.
Day 1: Thursday 14 March
Red Hatter Brian Proffitt carefully delivered our marketing notebook system.
In addition, Perry brought the following:
Dry-board markers
Dry-board flipchart easel
Opportunity drawing tickets
Leftover ribbons, mini-swag from 19x event
Safety scissors
Gaffers tape
Glue
And more!
Some of our ambassadors travelled in the morning, to catch earlier events and workshops. Others, however, arrived later to factor in traffic.
Portal to New Linux Ideas
The back of the Fedora booth this year…a sheet wall..
We met in the exhibit hall to check out the booth and to discuss strategy. Henceforth, we thought about our discussions and engagement to attract visitors. In contrast to SCaLE 20x, our booth was some distance away from the Red Hat booth.
The booth did not receive any free-standing banners this year. Thus, aside from our table cover, swag, and flip chart, we had few items to work with which had large Fedora branding. Soon, we discovered that some guests had initial challenges trouble locating our booth.
Upon dropping things off, some of us reconvened at the KWAAI Summit, new for 2024. Matt Small, Reza Rassool, Román Pineda, Khai Pham, John Willis, and others closed out the the event with an engaging Q&A, introductions, wrap up, and reception, for example.
Afterwards, Fedora joined the Red Hat and CentOS teams and others for a meal at the Yard House.
From L to R: Matthew Miller, Shaun McCance, Perry Rivera, and Carl George
Day 2: Friday 15 March
Checking in on the other variants…
Alejandro and I set out for breakfast Friday and discussed booth and expo plans for the days ahead. Eventually, we headed off to the NixCon track co-located in SCaLE 21x to learn about Nix. We were surprised to find a very packed workshop.
Booth Setup
After a brief look into these OSes, we returned to the Expo Hall to begin putting our booth together. For example, Scott arrived to install a notebook system that he configured with Flatpak pinball game running atop Universal Blue.
A guest re-discovers pinball on an immutable desktop
Red Hatters setting up a booth
Next, Perry set up a Fedora flip chart and pasted in a handy QR that Alejandro generated for guests to claim a Fedora badge. Then, Alejandro later wrote in our Fedora scheduled talks, which was handy for guests to take pictures of as they stopped by. Concurrently, Brian strategically set up swag items and carefully routed power within the booth.
Perry later stopped by the Red Hat booth to help raise the 5-person banner. It’s not heavy, however, but it is awkward and difficult to stand up with fewer than 5-people in attendance.
What an Exhibit at Fedora @ SCaLE 21x Linux Conference
At 10am, the Exhibit Hall opened. As a result, we had a steady stream of community throughout the reminder of the conference. Then, we took turns for breaks from time to time; however, as we were down a person, things felt a bit busier this year. We definitely missed not having Iván Chavero there.
We greeted approximately 400+ this day.
One of the many highlights from today was discovering a vending machine that dispenses temporary VMs. The buttons were quite amusing.
Eye-deal VM Vending Re-use.
At length, a few of us met up with Red Hat, CentOS, at El Portal Restaurant for dinner.
El Portal Restaurant for dinner.
Rob McBryde: Coordinator of Karaoke goodness.
Subsequently, we met up with Red Hat and CentOS later at Barney’s Beanery to enjoy karaoke and merriment.
Day 3: Saturday 16 March
Specifically, Brian Monroe, Scott, and Perry met up early Saturday morning to go over slide logistics for our Exploring Immutable Linux Desktops with Fedora presentation later that day. Afterward, we caught up with Alejandro at the booth to continue engaging with guests and greeted approximately 500+ this day.
Perry dropped in on a Digital Art / Krita open-source application workshop that went over how the fundamentals of using this tool. They gave pointers on how they use the app in their workflow, for instance.
Nicholas Maramba and Helen Ortiz present “Digital Art Makes You Smart”
Humberto Macias, lucky winner of a Fedora commuter tumbler.
Portal to the endless wonder of immutable desktops..
Guests listened attentively at the Immutable Desktop presentation
Scott Williams chats with Joshua Loscar at the Red Hat Booth
Jeff Carlson ponders his next move..
We also held opportunity drawings throughout the week to beckon more booth interest. Indeed, this proved a success. 40+ people stopped by for each draw.
Comparatively, Perry, Brian Monroe, and Scott later delivered their presentation to 45+ guests.
Thereafter, we re-joined Alejandro to finish up meeting our community at the booth for the expo day. We ate a late linner at the Dog Haus to reflect on the week’s events.
Soon, SCaLE 21x held their annual game night event. Next, we reunited with friends and associates to catch up and enjoy.
Day 4: Sunday 17 March
All of us packed up our rooms early Sunday. Naturally, Alejandro and I re-joined up at the Cordova Cafe for breakfast.
Consequently, we made our way over to the Exhibit Hall to finish up a final day with guests. Altogether, we had a little breather to visit the CentOS booth and say hello.
Shaun McCance and Carl George exhibiting at the CentOS booth
The final exhibit day brought in about 250 guests to our booth. Following, our team packed up the booth for transport.
Ultimately, to complete a fine Sunday, we attentively listened to an excellent closing keynote provided by Bill Cheswick.
Suggestion / Feedback Box Items for Fedora @ SCaLE 21x Linux Conference
In addition, we had a booth sign-in sheet for visitors to help collect feedback and suggestions about Fedora and related efforts.
From data compiled, we summarize these key highlights:
Marketing: Many requests for Fedora new logo swag and shirts. Could use stuffed animals, socks, or something different, USB stick. More creative ideas, sticker ideas (hex are popular), floor banners with new logo, DEI stickers were very popular. Portable swag (small and travel-ready) is great for travelers.
Marketing: One guest suggested a Fedora merch store where community could purchase Fedora logo swag/stickets/items. Above all, proceeds ideally would funnel back to Fedora community where needed.
Cross: One Debian guest continues prefers Debian for consistency, but wouldn’t mind using Fedora if a consistent spin was available. Potentially opportunity for immutable education or Debian/Ubuntu/NixOS etc. to Fedora presentations.
Info: Another Debian guest wanted to know key differences between Debian and Fedora. Ultimately, potential opportunity for explainer or migrating presentation or Why Use Fedora vs. ________?
Usage: One mentioned they are a Rawhide user.
Info: One requested more information about NeuroFedora. In other words, clearer information about what it is and the status of that Special Interest Group (SIG). Explainer card might be helpful at the booth.
Usage: One guest enjoys QT packages with DX build.
Licensing/Booth Info: One guest wanted clearer definition of the licensing relationship and sponsorship between Fedora / RHEL, if any.
Fedora Activity Day: It might be advantageous for Fedora to identify an organizer for a Fedora Activity Day (or two). For example, possible topics include: Debian to Fedora, command-line, Gnome, KDE, Immutable, Ambassadoring, Why Use Fedora vs. X?, etc.
Other: Changes for CentOS and Red Hat were points of concern and confusion for some guests.
Comm: Connect with Universal Blue folks, Lutris, Nobaro (sp?). Bazzite quality badges
Booth: Engagement with community at the table, opportunity drawing seems to be a success. Let’s get people in the front door of Fedora…for SCaLE 22x, provide challenge or engaging gimmick.
Thank You/Derivative: Ultramarine user says thank you for Fedora.
Thank You/Support: Thank you for Data Transit (GTFS) support
Magic Wormhole and Fedora are great. Ultimately, we referred this guest to Matthew Miller.
One guest tracking 39 and 40 Beta packaging and kernel. Definitely, this visitor expressed interest in helping with general or immutable. Additionally, we referred this guest.
In conclusion, we look forward to seeing you at next year’s SCaLE!
Snaps from Fedora @ SCaLE 21x Linux Conference
Perry Rivera and Kevin Howell
Conference Center Conversation Flows. Photo by Carl George
Patrick Finie and Perry Rivera
An engaging kernels workshop by Neil Gompa, Shaun McCance, and Carl George. Photo by Carl George.
Ana Ma and Perry Rivera
Romy Meyerson@SuSe stops by to visit to say hello..
Rob McBryde, Jaime Burwood, Katherine Nnanwubar, Perry Rivera, and Brian Proffitt
Perry Rivera and Siggy
Perry Rivera and Marc Provitt from SCaLE 21x’s Game Night event.
Discussing SCaLE strategies. L to R: Scott Williams, Brian Monroe, Shaun McCance, and Carl George.
Perry Rivera and Bill Cheswick
Clockwise, L to R: Joshua Loscar, Shaun McCance, Brian Proffitt, Cali Dolfi, Perry Rivera, Alex Acosta, Carl George, and Joshua’s oldest son discussing SCaLE week highlights at Lunasia Dim Sum House…
So I’ve run into this issue in the past but I finally started looking into why Python is soo slow at running basic math operations in a long loop, for example, simple stream cipher operations. You’ll see lots of suggestions to use numpy instead, however, I didn’t find this to be the most helpful. Since I like writing/reading C, I remembered that Python has a built-in ctypes module which is very helpful and useful if you are in need of specialized and optimized code paths. You can pretty easily pass in integer and byte array pointers with little complexity!
Most people only showed sympathy and respect for my family at that time.
Colleagues in the Debian world started sending me insults, telling me
that I am not a real Debian Developer. It is no surprise that there
is a suicide cluster in this group
(
Debian suicide cluster meets criteria from Public Health England).
Therefore, it is important to look at who really is a Debian Developer.
Origins of the term Debian Developer
Looking at the very first archived copy of an email from
the debian-project mailing list in 1994, we
find that Debian co-authors are using the term
Debian Developer four years before there was a trademark. That is
four years before the Debian Project constitution. The term
Debian Developer is completely valid
for somebody who has done significant creative work over many
decades. In plain English, the term Debian Developer can mean
three things: somebody who possesses the skill of creating
Debian software, somebody who has an authorship interest in
the Debian software and thirdly, but lastly, somebody who is
a member of the clique. Copyright law does not require somebody
to be a member of the clique. I never joined the Debian Project
Unincorporated Association, I have always used the term
Debian Developer first and foremost to describe myself as an author with
moral rights in the creative work.
Legitimate interest: a very long history of voluntary contribution
Some of us started doing Debian as a hobby alongside other hobbies
such as amateur radio. One of the early Debian Project Leaders,
Bruce Perens, also notably came to Debian for amateur radio purposes.
I passed the amateur radio exam in 1993,
when I was 14 years of age.
My first years of voluntary activities in amateur radio and free software
were during a time when I was legally a child. I didn't receive any
payment for some of those activities. I offered my time on the basis
that I was gaining skills and helping real communities.
Around the same time, while I was still legally a child, I came to
appreciate the fact that there are some adults who exploit talented and
precocious youngsters by trying to direct the work that is being undertaken
and failing to disclose or share financial benefits.
The Debian Project constitution was originally published on
10 September 1998,
some time later.
The trademark was only registered later on 21 December 1999
Looking at the Scientologie.org UDRP verdict,
(
WIPO UDRP case D2000-0410)
the panelists
gave some weight to those possessing a copyright interest that predates
the registration of a trademark or a copyright interest arising from
a situation that intersects with the history of the trademark.
The spirit of the Scientologie.org UDRP verdict can
be extracted in good faith to questions like who can use the term
Debian Developer.
Legitimate interests: the promise of recognition
The misfits behind the WIPO insults do not pay the rest of us anything
for our collaboration in creating the Debian software.
They told us that the only thing we get in return for our creations
is the recognition.
Using the term Debian Developer is interchangeable with
recognition for our skills and recognition of our status as voluntary,
un-paid joint authors
who are not compensated in any manner other than recognition.
They are now using the debian.org web site and the trademark
to give people negative recognition. This is like bouncing a cheque.
In the circumstances, it seems entirely appropriate for me to follow
through on the promise of recognizing people. The misfits have provided
a list of the domains along with the dates that each domain name was
registered. On the list, the name debian.plus is the first
name registered. debian.plus was registered for the purpose
of delivering on the promise of positive recognition to the
authors and our work.
Debian promises recognition, I take the following quote from
the latest Debian law suit where they admit using the promise of recognition
to lure people into working for free:
64. ... un des avantages importants de travailler pour la communauté Debian est la valeur de sa réputation dans le domaine, à la fois professionellement et dans la communauté. ...
The motivations of the authors also are varied, but the coin that they get paid in is often recognition, acclaim in the peer group, or experience that can be traded in in the work place
you are recognized for your contributions ... Did you ever have a boss who takes credit for your work? Not in Debian.
In short, there is a big emphasis on working for recognition instead of a salary. They gave us the promise of recognition and that gives rise to a legitimate interest in using the trademark in domain names for web sites about our work.
Moreover, it means once we gain the status of Debian Developer in the
sense of being a joint author, as the term has been used since at least 1994,
they can't bounce the cheque and extinguish
our copyright / recognition / status as these things are interchangeable.
Bad faith: not every co-author wants to be a member of something too
In a number of jurisdictions, we have seen people establishing
associations, some of them legally incorporated, some of them unincorporated,
where they now use the term Debian Developer interchangeably
with the status of a member rather than the status of an author.
Over the years, people have regularly protested against this practice
of conflating authorship and membership.
In 2005, some Debian Developers in the UK created the
Debian UK Society. They published a
proposed constitution / articles of incorporation suggesting
that every Debian Developer in the UK would become
a member of the Society unless they opt-out.
Some authors felt this was a forced membership, similar to forced
membership of a trade union.
The Debian UK Society (DUS) asserted
automatic membership of debian developers (much like that sometimes
suggested for SPI and rejected every time) and some of its members
insulted and lied about me instead of fixing that bug.
Credit to them for fixing it eventually.
Steve McIntyre: Membership of the society consists of the set of registered Debian developers resident in the UK, bar those who have deliberately opted out.
Why would you force authors to downgrade their rights from their status
under copyright law to a lower status as described in the
Debian UK Society constitution?
Under copyright law, joint authors can't expel each other
Under the constitutions of these associations, they purport that
authorship and membership can be simultaneously extinguished on the
whims of the leader of the day.
Some of us never joined any of these associations yet they claim,
in bad faith, that they have the power to "expel" us.
The status of Debian Developer is independent of membership status
Nonetheless, when we examine the words from Steve McIntyre above, we
can see that the status of being a Debian Developer
(co-author or joint author) is something distinct
from being a member.
The distinction is therefore clear to those who created those periphery
associations around the copyrighted work.
Who has a copyright interest in the Debian GNU/Linux?
Version 1.9.16 of sudo will feature a new option for logging: json_compact. Why is this important? This new format can easily be read and parsed by a log management software, like syslog-ng.
Note that in this blog I am showing you a sudo feature which has not yet been released officially. You have to compile sudo yourself. By all means, if you have any other application writing JSON-formatted log messages, you can apply most of what you read here with slight modifications.
Before you begin
You need JSON-formatted log messages. This blog is about working with the json_compact logs from sudo. You need version 1.9.16 or later for this, or you can also compile sudo yourself from git sources. It is described in my latest sudo blog at https://www.sudo.ws/posts/2024/04/when-it-comes-to-sudo-logging-pretty-is-not-always-better/ .
Naturally, you can also use any other JSON-formatted logs, as long as each message takes a single line.
Configuring sudo
You can enable the new json_compact logging format in sudo for log files (JSON formatting for syslog always uses a variant of the compact format) by adding these two lines to your sudoers file using visudo:
Certainly, the name of the file could be anything. I use my initials in file names to make sure they are unique and do not collide with existing names on the system.
Once you have saved the sudoers file, you should test sudo. Run something using sudo and check the content of the file you just specified in the sudoers file. Instead ofreadable, multi-line messages, you should see single-line JSON-formatted messages like this:
This is not easy to read. However, syslog-ng and most other log management software can read single-line log messages out of the box. You just have to point them at the file name.
Configuring and testing syslog-ng
Here is my initial syslog-ng configuration: append it to syslog-ng.conf or create a new configuration snippet under /etc/syslog-ng/conf.d/ with a .conf extension.
This configuration does not do much. It reads the JSON-formatted file line by line. The no-parse flag means that syslog-ng does not parse the message as an RFC3164-formatted syslog message, as it is normally done by default. Instead, syslog-ng uses a JSON parser to turn the message into name-value pairs.I usually use JSON formatting to save name-value pairs into a text file, but as the initial format is JSON, I use WELF formatting here.
If you take a look at that file, you should see similar messages to these:
Even if you do not need logs in this format in the long run, this step is useful in multiple ways. First of all, you can see that message parsing works. You can also see all (well, most) of the name-value pairs created by syslog-ng from the log message. You can use this log file while refining the syslog-ng configuration and delete / comment it out from the configuration later.
Here is a bit more fun of configuration, building on the previous one. This one adds two more destinations:
source s_sudojson {
file("/var/log/czpsudo2" flags(no-parse));
};
parser p_json {
json-parser();
};
destination d_sudo {
file("/var/log/sudowelf"
template("$(format-welf --scope nv_pairs --exclude MESSAGE --exclude accept.submitenv)\n\n")
);
file("/var/log/sudofreetext"template("${DATE} user ${accept.submituser} ran ${accept.command} on host ${HOST} using sudo\n"));
};
log {
source(s_sudojson);
parser(p_json);
destination(d_sudo);
if (match("root" value("accept.submituser"))) {destination { file("/var/log/sudoroot" template("Oops, why did root use sudo to run ${accept.command}\n")); };};
};
The file sudofreetext uses name-value pairs parsed by syslog-ng from the JSON-formatted logs to create new log messages.
The other log file is only written to if user root executes a command using sudo. Of course, there can also be some legitimate uses, but I just come across the user becoming root way too often while still using sudo to run commands. Copy & paste from blogs and documentation :-)
The log files will look something similar to these:
leap154b:/var/log # cat sudofreetext
Apr 10 12:38:49 user czanik ran /usr/bin/ls on host leap154b using sudo
Apr 10 12:38:54 user root ran /usr/bin/ls on host leap154b using sudo
leap154b:/var/log # cat sudoroot
Oops, why did root use sudo to run /usr/bin/ls
What is next?
From this blog, you could learn how to work with JSON-formatted log files. The sample configurations showed you how to get started when developing a configuration. I hope I was not the only one having fun while working with these configurations. Surely, in a production environment, you will use different message formats or use other name-value pairs. However, you can use the examples with minor modifications to achieve those.
-
If you have questions or comments related to syslog-ng, do not hesitate to contact us. You can reach us by email or even chat with us. For a list of possibilities, check our GitHub page under the “Community” section at https://github.com/syslog-ng/syslog-ng. On Twitter, I am available as @PCzanik, on Mastodon as @Pczanik@fosstodon.org.
Aprovecharé para enseñar alguna de las últimas cosas en las que trabajo en el proyecto SMALL GLAM SLAM Pilot 1 con el que estamos preparando la infraestructura digital del futuro centro de documentación digital de LaOficina.
El taller tendrá lugar el 18 de abril por la tarde en la biblioteca María Moliner y la entrada es libre.
Chamando todos os cientistas de dados, sobretudo os que lidam com séries temporais, como eu, para ver um experimento.
Mediram a frequência cardíaca de Yuja Wang, a pianista erudita mais badalada do momento — e a mais gata também — enquanto executava uma façanha sem precedentes: tocar todos os 5 concertos de piano de Rachamninoff em uma única apresentação de mais de 4 horas de duração. Mediram também a frequência cardíaca do regente Yannick Nézet-Séguin, de alguns músicos da orquestra, e também de ouvintes na platéia, no Carnegie Hall de Nova York, em 28 de janeiro de 2023.
Entrevistas, explicações e análises de dados podem ser vistas no vídeo do Carnegie Hall. Algumas revelações dos dados coletados são óbvias: devido ao esforço físico, o coração de Yuja dispara conforme a densidade da partitura aumenta. Mas outras constatações são também muito interessantes, como o sincronismo cardíaco — ou emocional — entre a pianista, público e músicos.
Um experimento multi-disciplinar absolutamente lindo, inédito e necessário.
In the UDRP dispute over WeMakeFedora.org,
the legal panel found
that communications from IBM Red Hat had authorized
use of the domain name and therefore, IBM Red Hat themselves were acting
in bad faith by trying to retrospectively launch a dispute.
The authorizations published on the debian.org web site
are even more unambiguous, unconditional and explicit than the
authorizations that IBM Red Hat gave to the owner of WeMakeFedora.org.
Therefore, Software in the Public Interest, Inc has no right to
complain about third party web sites that "look like" debian.org.
Using the standards set by the WeMakeFedora.org verdict,
we can say clearly that Software in the Public Interest, Inc is
acting in bad faith when it complains about similar web sites.
We don't even need to pay a legal panel to tell us that because
the hypocrisy has a certain smell about it. Debian is rotting from the
inside.
It is important to think about the consequences for the volunteers
running independent web sites. Many of us do this without payment.
We do this as a hobby. Dealing with harassment from lawyers creates
stress and takes time away from our families. If a WIPO panel was
to make a declaration of bad faith about us simply because we don't
know how to write an adequate response and can't afford a lawyer then
the rogue WIPO verdict could have negative consequences for our
employment, ability to borrow money and ability to obtain or renew
essential insurance policies for our homes and our trade.
When you think about all those potentially negative consequenes for
us as volunteers, it is really wrong for SPI to seek such consequences
despite the fact they authorized use of the logo and theme.
That is why it is so important for the legal panel to make a verdict
of bad faith against SPI themselves.
Legitimate interest: redistribution of the Debian software is
explicitly authorized
With this authorization, any person who obtains a copy of the
software is entitled to redistribute it.
The DebianGNULinux.org
domain name was registered to do exactly that, to redistribute
copies of the Debian software. This activity has been authorized.
Remarkably, in one of their claims submitted to another tribunal,
the misfits explicitly describe a web site redistributing Debian
as an outrageous crime, despite the fact the DFSG and the license
statement referred to earlier explicitly authorize redistribution of
genuine copies of Debian GNU/Linux.
Such a flagrant violation of the principles in the DFSG appears
to be bad faith on the part of the complainant.
Legitimate interest: use of the logo is authorized
The page describes two versions of the logo, the open logo
and the restricted use logo.
The page gives a free-for-all license to use the open logo.
The logo I am using on pages about my Debian work is the open logo.
Here is the text of the authorization from the trademark holder:
The Debian Open Use Logo comes in two flavors, with and without “Debian” label.
The Debian Open Use Logo(s) are Copyright (c) 1999 Software in the Public Interest, Inc., and are released under the terms of the GNU Lesser General Public License, version 3 or any later version, or, at your option, of the Creative Commons Attribution-ShareAlike 3.0 Unported License.
Legitimate interest: use of Debian-themed web page style
The Debian web page style is used extensively on third party web sites
run by individual co-authors and volunteers.
At the bottom of every page on the main
www.debian.org
web site there is a link to a dedicated page about the licenses
(authorization) to re-use the theme and content of www.debian.org.
Since 25 January 2012, the new material can be redistributed and/or modified under the terms of the MIT (Expat) License or, at your option, of the GNU General Public License; either version 2 of the License, or (at your option) any later version (the latest version is usually available at https://www.gnu.org/licenses/gpl.html).
Work is in progress to make the older material compliant with the above licenses. Until then, please refer to the following terms of the Open Publication License.
This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, Draft v1.0 or later (you can read our local copy, the latest version is usually available at http://www.opencontent.org/openpub/).
“Debian” and the Debian Logo are trademarks of Software in the Public Interest, Inc.
The complainant publishes the source code for the web site theme.
This makes it easy for anybody empowered by the above license to download
the theme and use it when creating their own site.
At the bottom of every page on Debian.org, they promote
the source code for the web site with a link text
"Web site source code is available".
Bad faith: complainant reneges on existing authorizations
As noted in the statements on legitimate interest, the
complainant has clearly authorized many of the things they complained
about.
The Debian Social Contract, which states "We will not hide problems",
authorizes discussion of controversial technical, social and ethical
topics. In fact, it is more than an authorization, it encourages
such discussions and publications. Therefore, their complaining
about what is published on these web sites is itself an act of bad faith.
They authorized use of the logo, as discussed, so their complaining
about use of the logo is itself bad faith.
They put the web site theme and content under the open source licenses,
as discussed above, so their complaining about sites with a similar
appearance is itself bad faith.
Overall, for their claim of bad faith to supercede these authorizations,
they would have to demonstrate some extraordinary acts of wrongdoing,
for example, to show that a web site was using the trademark, domain
name and logo to distribute a virus. They provide no evidence of
such wrongdoing.
Legal panels looking at the disputes have so far refused to make
any finding about who owns a copyright interest in Debian.
Precedents in the UDRP have determined that any joint author has
a legitimate interest in using the Debian name as part of a domain name.
The example that people have been discussing is the Scientologie.org
dispute
(
WIPO UDRP case D2000-0410).
Copyright is important because it gives rise to legitimate interests
of the co-authors who want to register their own Debian domain names.
Co-authors of a work are
equal. Notions of exclusive memberships, expulsions and
demotions violate the principle of being equal.
The implication of this statement is clear: the Scientologie.org
precedent for a single entity having a copyright interest can be relied
upon by any equal co-author of a work. The precedent is not only
applicable to cases with a single author and doesn't require all
authors to be in agreement (or Debian groupthink) with each other.
In the most recent Debian UDRP vendetta, the legal panel wrote:
The Panel confirms that this finding does not imply
that it has taken any view of the ownership of copyright in DEBIAN
software. Indeed, it is unable to do so on the evidence before it.
Here I try to fill that gap and provide evidence about Debian GNU/Linux
copyright, including my own copyright interest.
Debian Developers are asserting that:
Debian GNU/Linux is a Collective Work, which has a special meaning in copyright law
The aforementioned Collective Work is created not by a single author but by Joint Authors
Debian GNU/Linux copyright is based on the US law and may be influenced by the laws of other countries where various Debian Developers and Debian Project Leaders have resided over the years
What a WIPO legal panel told us about Debian GNU/Linux copyright
This analysis has been conducted by long time Debian Developer Daniel
Pocock.
Various people have been holding up copies of one of the UDRP vendetta
verdicts. Therefore, they are clearly aware of the references to the original
Scientologie.org verdict and the logic in that verdict
(
WIPO UDRP case D2000-0410).
The two lines quoted above from the 2022 panel are significant and as the misfits have
submitted this document in support of their demands again in 2024, with
the help of legal counsel, we are surprised they have not tried to answer
that question
proactively. It appears that they don't care too much about documenting
and protecting the exclusive economic rights of a copyright owner or
the moral rights of an author.
On the distinction between the exclusive economic rights of a copyright
owner, I note that none of us Debian Developers, being the co-authors
of Debian, have ever been asked to assign our rights to any third-party
copyright owner. The misfits have not submitted any evidence purporting
to prove that such an assignment did take place. Therefore, there is no
copyright owner having exclusive economic rights over the Debian software.
By default, the rights rest with the authors who did the work. Despite
having clearly
read the panel's comments, the misfits have not submitted any evidence
claiming that any such party exists with exclusive economic rights
as a copyright owner of the Debian software.
Where is the real Debian license statement?
Oddly enough, Debian documents and files in a Debian system refer
to the licenses of the individual packages being distributed. It
was hard to find an actual example of a copyright statement or
license for Debian itself as a collective work.
The
Debian Project constitution of 1998, referred to above,
encourages Software in the Public Interest, Inc to register a
trademark. It says nothing about copyright in the existing body of
work.
Here are the words from the original constitution:
Since Debian has no authority to hold money or property, any donations for the Debian Project must be made to SPI, which manages such affairs.
SPI have made the following undertakings:
1. SPI will hold money, trademarks and other tangible and intangible property and manage other affairs for purposes related to Debian.
So people can donate intangible property like copyright to SPI if they make a personal decision to do so. The constitution did not oblige us to make such donations/assignments.
This situation is well known in open source software development.
Some companies ask their contributors to sign a Contributor License Agreement
or an assignment granting all their rights to a central entity with
exclusive copyright.
Such an assignment can't take place through a majority vote, such an
assignment or transfer of rights to a single entity would require
the unanimous consent of every single author who ever contributed
to Debian. In the case of those authors who are deceased, we would
need to obtain consent from their estates.
Continuing the search for a Debian license,
on the ISO installation media, I found the file
isolinux/f10.txt which contains the very brief text:
COPYRIGHTS AND WARRANTIES
Debian GNU/Linux is Copyright (C) 1993-2016 Software in the Public Interest,
and others.
The Debian GNU/Linux system is freely redistributable. After installation,
the exact distribution terms for each package are described in the
corresponding file /usr/share/doc/<packagename>/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
It asserts that copyright is owned by Software in the Public Interest,
and others. Most of us are individual private volunteers and we
have never personally chosen to grant or assign our copyright interest
to Software in the Public Interest. I became curious about who put
this statement into the ISO image.
Debian is a collective work under the above US copyright law.
The work was initiated in 1993 by Ian Murdock in the United States.
In a Collective work (US), the authors (or co-authors) are selecting works
from third parties and arranging them into the final product, Debian,
a collective work. The decision making process that involves selecting
third party works and the decision making process that involves
arranging the third party works gives rise to the moral rights
of authorship in the Debian collective work.
The “authorship” in a collective work comes from the original selection, coordination, and arrangement of the independent works included in the collective work.
In the Debian world, the independent works are referred to as "upstream" source code. The authors of independent works are referred to as "upstream authors" or just "upstream".
The Debian maintainer guide describes the process of jointly selecting the independent works for inclusion in Debian. In particular, co-authors are required to create a public "Intent To Package" (ITP) report in the bug tracking system (BTS) so that other co-authors can discuss the merits of the selection decision. The requirement to engage in a shared discussion for every selection decision gives rise to joint authorship rights.
Moreover, the person who creates the package importing the independent work into Debian is required to create a manifest describing the inclusion of the independent upstream work. This manifest is the debian/control file. The Debian Policy Manual provides a list of fields in the debian/control files.
Some of these fields are dedicated to the coordination and the arrangement of the independent works within a Debian system.
Coordination of the independent contributions: the package dependency fields describe the relationships between packages that have to be installed together or which conflict with each other. In many cases, when a library package is a dependency for other packages, we have to ensure that the version of the library package in Debian is compatible with the dependent packages. We have a formal process of coordination in this case, the Transition process. Populating the dependency fields in the debian/control file and participating in a Transition process, either as the producer or the consumer of a dependency, are examples of coordination of the independent works from upstream authors.
Here are some examples where I personally engaged in these actions:
The fields Section and Priority impact the arrangement of the contributions from the perspective of the user. The person completing the values in these fields is engaged in the process of arrangement of the contributions in a collective work.
Therefore, the development of Debian includes features of
both a collective work and a work of joint authorship at the same time.
Moreover, due to processes such as library transitions, NMU and our
system of voting on certain decisions, any co-author may influence the
way that other co-authors are integrating the independent upstream works
into Debian. This cross-pollination of ideas and effort is a well known
feature of Debian. In other Linux distributions, the developers are
a little bit more siloed from each other.
Every two years, an official stable release of the Debian software
is released to the public. This process of releasing involves
declaring a version number that corresponds to a particular subset
of the contributions that are in a working state at the time of the
release. Even if a Debian Developer's contributions are obstructed
from inclusion in future releases, or if a Debian Developer commits suicide,
their work is still present in all the past releases that have been
published.
My own contributions are included in a number of these Debian releases
over the years.
This
report finds my name in changelogs and copyright files.
There are 21 pages of results.
Shooting themselves in the foot
To declare that the Debian Developers do not have authorship
rights at all would be incredibly de-motivating.
Future volunteers may be deterred from contributing their
intellectual property and their time.
Bad faith: the complainant is gaslighting about authorship and membership
The complainant appears to pivot back and forth between concepts from
copyright law and from the law of associations.
Consider the case when somebody begins contributing to Debian.
There is no such thing as a "New member" process. Rather, it has
historically been called the "New maintainer" process. We can see that
clearly in the
name of the
debian-newmaint mailing list.
The word "maintainer" primarily implies somebody is doing creative work to
select, coordinate and arrange more independent works into Debian.
Then we have the guide for the
New Member process, which was previously known as the New
Maintainer process. In step 3, explained in that page, the new contributors
are asked to agree to the Debian Social Contract,
the Debian Free Software Guidelines and the
Debian Machine Usage Policy. The former is ultimately about our relation
as authors, not as members and the terms under which we license our
work to the rest of the world.
The new maintainer/member guide doesn't ask people to ratify
their adherence to the constitution. The notion of joining an association,
whether it is incorporated or not, is inseparable from consenting to
be governed by and uphold the association's constitution. The
only people who ever ratified the constitution were
86 co-authors
in 1998 (23% of the developers at that time) who wanted to have
a constitution.
Somebody who did not ask to be a member can't be expelled.
Somebody who is not an employee can't be demoted or sacked.
Yet we have seen some of the leadership figures insist on having
these powers over a
series of victims. The title Debian Project Leader
implies just that: to lead, not to give orders.
The insinuation that concepts of expulsions and demotions can
be applied to co-authors is an example of gaslighting.
Copyright law is very clear: co-authors of a work are
equal. Notions of expulsions and demotions violate
the principle of being equal.
The fact that they are knowingly and deliberately trying to obfuscate
our moral rights as co-authors, giving us nothing in exchange
for the status they are taking away, is an aggravating factor
that justifies the finding of harassment and bad faith against
the complainant.
Bad faith: use of an administrative process to extinguish the moral rights and recognition of co authors
The paper notes that the Nazis used administrative law to
frustrate the rights of authors, just as misfits are using a WIPO
administrative process to harass and intimidate a Debian co-author.
Quoting the journal article:
Despite the fact that written IP legislation in Nazi Germany
did not include specific exclusions for Jewish applicants and authors,
in practice, they were excluded by administrative measures alone
rather than legal ordinances.
The misfits frequently use the same language, the word "exclude" comes
up again and again. Harassment, UDRP rule 15(e)
Josh and Kurt talk about a Notepad++ fake website. It’s possibly not illegal, but it’s certainly ethically wrong. We also end up discussing why it seems like all these weird and wild things keep happening. It’s probably due to the massive size of open source (and everything) now. Things have gotten gigantic and we didn’t really notice.
First, you of course need a video to test. On a modern desktop computer, you want a 4k 60fps video or better to have something that pushes your CPU to the limits so you know when it doesn’t work. Of course, the recommendation has to be Big Buck Bunny at the highest of qualities – be aware that the most excellent 4000×2250 @ 60fps encoding is 850MB. On my Intel TigerLake, that occasionally drops frames when I play that with software decoding, and I can definitely hear the fan turn on.
When selecting a video file, keep in mind that the format matters.
Second, you need hardware decoding. That is provided by libva and can be queried using the vainfo tool (which comes in the `libva-utils` package in Fedora). If that prints a long list of formats (it’s about 40 for me), you’re good. If it doesn’t, you’ll need to go hunt for the drivers – due to the patent madness surrounding video formats that may be more complicated than you wish. For example, on my Intel laptop on Fedora, I need the intel-media-driver package which is hidden in the nonfree RPMFusion repository.
If you look at the list from vainfo, the format names give some hints – usually VP9 and MPEG2 exist. H264 and HEVC aka H265 are the patent madness, and recent GPUs can sometimes do AV1. The Big Buck Bunny video from above is H264, so if you’re following along, make sure that works.
Now you need a working video player. I’ll be using gtk4-demo (which is in the gtk4-devel-tools package, but you already have that installed of course) and its video player example because I know it works there. A shoutout goes out to livi which was the first non-demo video player to have a release that supports graphics offloading. You need GTK 4.14 and GStreamer 1.24 for this to work. At the time of writing, this is only available in Fedora rawhide, but hopefully Fedora 40 will gain the packages soon.
If you installed new packages above, now is a good time to check if GStreamer picked up all the hardware decoders. gst-inspect-1.0 va will list all the elements with libva support. If it didn’t pick up decoders for all the formats it should have (there should be a vah264dec listed for H264 if you want to decode the video above), then the easiest way to get them is to delete GStreamer’s registry cache in ~/.cache/gstreamer-1.0.
If you want to make sure GStreamer does the right thing, you can run the video player with GST_DEBUG=GST_ELEMENT_FACTORY:4. It will print out debug messages about all the elements it is creating for playback. If that includes a line for an element from the previous list (like `vah264dec` in our example) things are working. If it picks something else (like `avdec_h264` or `openh264dec`) then they are not.
Finally you need a compositor that supports YUV formats. Most compositors do – gnome-shell does since version 45 for example – but checking can’t hurt: If wayland-info (in the wayland-utils package in Fedora) lists the NV12 format, you’re good.
And now everything works.
If you have a 2nd monitor you can marvel at what goes on behind the scenes by running the video player with GDK_DEBUG=dmabuf,offload and GTK will tell you what it does for every frame, and you can see it dynamically switching between offloading or not as you fullscreen (or not), click on the controls (or not) and so on. Or you could have used it previously to see why things didn’t work.
You can also look at the top and gputop variant of your choice and you will see that the video player takes a bit of CPU to drive the video decoding engine and inform the compositor about new frames and the compositor takes a bit of CPU telling the 3D engine to composite things and send them to the monitor. With the video above it’s around 10% on my laptop for the CPU usage each and about 20% GPU usage.
And before anyone starts complaining that this is way too complicated: If you read carefully, all of this should work out of the box in the near future. This post just lists the tools to troubleshoot what went wrong while developing a fast video player.
RPMs of PHP version 8.3.6 are available in the remi-modular repository for Fedora ≥ 38 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...) and in the remi-php83 repository for EL 7.
RPMs of PHP version 8.2.18 are available in the remi-modular repository for Fedora ≥ 38 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...) and in the remi-php82 repository for EL 7.
RPMs of PHP version 8.1.28 are available in the remi-modular repository for Fedora ≥ 38 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...) and in the remi-php81 repository for EL 7.
The Fedora 39, 40, EL-8 and EL-9 packages (modules and SCL) are available for x86_64 and aarch64.
We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.
Week: 08 April – 12 April 2024
Infrastructure & Release Engineering
The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work. It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.). List of planned/in-progress issues
Fedora Infra
In progress:
Adding template to handle monitoring of external hosts to zabbix
Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special Interest Group that creates, maintains, and manages a high quality set of additional packages for Enterprise Linux, including, but not limited to, Red Hat Enterprise Linux (RHEL), CentOS, Scientific Linux (SL) and Oracle Linux (OL).
This is the 119th issue of syslog-ng Insider, a monthly newsletter that brings you syslog-ng-related news.
NEWS
Collecting One Identity Cloud PAM Essentials logs using syslog-ng
One Identity Cloud PAM Essentials is the latest security product by One Identity. It provides asset management as well as secure and monitored remote access for One Identity Cloud users to hosts on their local network. I had a chance to test PAM Essentials while still in development. While there, I also integrated it with syslog-ng.
From this blog, you can learn what PAM Essentials is, and how you can collect its logs using syslog-ng. My next blog will show you how to work with the collected log messages and create alerts when somebody connects to a host on your local network using PAM Essentials.
Dedicated Windows XML eventlog parser in syslog-ng
Version 4.6 of syslog-ng introduced windows-eventlog-xml-parser(), a dedicated parser for XML-formatted event logs from Windows. It makes the EventData portion of log messages more useful, as it combines two arrays into a list of name-value pairs.
Most log messages fit on a single line. However, Windows and some developer tools and services, like Tomcat, write multi-line log messages. These can come in various formats. For example, new log messages start with a date in a specific format. You use the multi-line-prefix() of the syslog-ng file() source to send multi-line messages as single messages instead of line by line.
I must admit that I have never seen multi-line logs in production. I am not a developer, do not run Tomcat or Windows. However, recently I tested a software on Windows, which produced multi-line log messages.
Há mais de 10 anos, por todas as últimas empresas que passei — umas 3 ou 4 — MacBook é o laptop padrão que profissionais high-tech usam. Ou é no mínimo possibilidade de opção ergonômica oferecida pela empresa, que não precisa de nenhuma aprovação ou justificativa para se obter, basta pedir diretamente ao TI.
MacBook é indiscutivelmente equipamento melhor do que um laptop médio baseado em Windows.
A tela de alta densidade (conhecida como Retina) é mais confortável aos olhos e faz caber mais informação.
O equipamento é mais coeso, mais fino e mais leve para se carregar na mochila.
A bateria dura muitas horas mais, parece que nunca acaba.
O laptop esquenta menos por ter CPU mais eficiente e mais moderna que as dos laptops projetados para Windows.
O teclado é melhor, permite mais possibilidades de escrita, correção e substituição de texto, e tem melhor suporte a Unicode.
O trackpad é maior, mais ergonômico e tem mais funções.
E o sistema operacional, baseado em Unix, é ambiente mais familiar para high-tech.
Repare que não entrei no mérito de segurança, facilidade de uso e nem boniteza do macOS. Isso é bem menos relevante para este contexto e convenhamos que o Microsoft Windows não deixa a desejar, é também bem OK em todos esses quesitos. A preferência continua girando em torno do hardware.
O conjunto citado e mais muitos outros pequenos detalhes faz do MacBook ser plataforma preferida por profissionais high-tech, e outros também, que passam muitas horas do dia na frente de um computador.
É por isso que quem experimenta dificilmente volta atrás para hardware baseado em Windows.
MacBook é equipamento mais caro?
Se você procurar no mercado de laptops Windows as linhas com as mesmas características de tela, ergonomia, teclado etc, vai perceber que os equipamentos serão mais caros ainda do que um MacBook equivalente. Como referência, as linhas equivalentes são XPS da Dell, Spectre ou Envy da HP, X1 da Lenovo.
O mercado de laptops Windows, por ser mais competitivo, inova no palavreado para vender refugo, ao invés de criar produtos melhores. Digo isso porque já fiz essa pesquisa e terminei frustrado.
A empresa não prefere ter escritório da Av. Paulista, ao invés de Alfaville, apesar de “ser mais caro”?
A empresa não optou por instalar ar-condicionado, ao invés de ventiladores ou manter janelas abertas, apesar de “ser mais caro”?
Pois então, optar por oferecer aos funcionários um bom laptop é o mesmo tipo de escolha.
Então não é uma questão monetária e sim de usar características mínimas para os padrões de hoje em dia.
The Fedora Diversity, Equity, & Inclusion (DEI) Team rounded out 2023 with a focus on celebrating the 20th anniversary of the Fedora Project and officially welcoming new team members. This post is a brief recap of the fourth quarter of 2023 (October to December) for the DEI Team. The end of the year is typically a slower time in Fedora due to holidays, but we had some major highlights in 2023 Q4 anyways:
Shifted our sprint planning from a monthly cadence to a quarterly cadence.
Fedora Pride was established, and represented at some of our virtual events.
This post summarizes these highlights and also paints a picture of what we were looking forward to in 2024 Q1. Read on to get the full scoop!
Shifting from monthly to quarterly planning
In our previous sprint report, the new GitLab-centered workflow was introduced. We originally launched with a monthly cadence. However, we quickly realized that a monthly cadence was not the right fit for our team. Many of our projects span many months, like planning an event. This means that a few things get done every month, but many ongoing tasks shift every month.
Adopting a quarterly format worked better because that better matches the cadence at which the Fedora DEI Team operates. Event planning might span two to three months. This means that most events could fit into a three-month window. Some things still get shifted from quarter to quarter, but as long as we anticipate that, it works fine for us!
Most importantly, a quarterly cadence means that we can always clearly describe what was accomplished, what we are working on, and we can speculate on the future. Our hope is that it also makes reports like this easier to read!
A successful Fedora Appreciation Week
The previous report mentioned that planning for the Fedora Appreciation Week was underway. And it successfully happened! For context, Fedora Appreciation Week first started in 2018 for the 15th anniversary of Fedora. Fedora Appreciation Week, abbreviated as FAW, is a week-long event organized by the Fedora DEI Team. It is dedicated to celebrating the efforts of Fedora Project contributors and expressing gratitude to one another. Fedora Appreciation Week happened from November 6–12, 2023.
Thanks a lot to everyone who contributed to making Fedora Appreciation Week happen! Your participation and contributions have made this event a truly special and memorable experience. As we move forward, let’s carry the spirit of gratitude with us and continue to acknowledge the exceptional efforts of our Fedora community.
Welcoming Robert and Emma to the DEI Team
Our Fedora DEI Team continues to grow! Although neither of these two names were new to us, we officially nominated and voted Robert Wright and Emma Kidney as the newest inductees to the Fedora DEI Team. Robert is an infrastructure contributor and co-lead to the Community Operations Community Initiative. Emma is a Design Team member and she has been a key contributor for managing graphic design and brand identity for events like Fedora Flock and our release parties. She also designed our team logo!
We are so excited to have Robert and Emma join us as official team members! Although their contributions span before they were officially inducted, we cannot wait to see them continue to contribute and shine in our team.
Fedora Pride establishes as a Fedora DEI Community
In Q4 2023, Fedora Pride achieved several notable accomplishments:
Successfully hosted a release party mini-event for Fedora 39, featuring an engaging session of the game Among Us. This event fostered community engagement and celebrated the new release.
Held meetings in October 2023 (and a few months of 2023). The session focused on strategizing future initiatives and strengthening community involvement.
Initiated the development of a new GitLab project to hold SIG identified issues.
Looking ahead to 2024 Q1
At the time of publishing, this report is already coming out at the end of 2024 Q1. Oops! That means you can expect to see a 2024 Q1 article later this April. However, to give you an early sneak preview, this is a summary of what the DEI Team was working on from January to March 2024:
Fedora Council Hackfest: The Fedora Council held its annual in-person hackfest in February 2024 for annual planning. The DEI Advisor, Jona Azizaj, represented the DEI Team in conversations about the Fedora Strategy and more. Look out for more about the Council Hackfest in future Community Blog posts.
Fedora Week of Diversity: Planning is already underway for the DEI Team’s next virtual in June 2024. Fedora Week of Diversity is the successor to Fedora Women’s Day, originally started in 2016 as a celebration of the diverse people who make up our Fedora community. Volunteers are needed! See the issue for more details.
GNOME collaboration: Following the initial meeting of some DEI Team members with the GNOME community at GNOME Asia 2023, we wanted to continue collaboration with the GNOME D&I team. Jona Azizaj and Justin W. Flory continue to represent the Fedora community there upstream and provide guidance based on past experiences with the Fedora DEI Team.
Marketing Team collaboration: Following up on a request from Marketing Team member Daimar Stein, the DEI Team is working together with the Marketing Team to provide more perspectives and ideas to messaging campaigns. Since the issue was opened, we are working on an outreach timeline for Fedora Week of Diversity and collaborated on a post for World Autism Acceptance/Awareness Day.
Stay tuned for the full 2024 Q1 report in an upcoming article. In reflection, the end of 2023 was a busy ending to a year that saw the comeback of the DEI Team after a dormant period. As we continue building up our capacity and focusing in our team vision and mission, we are also slowly growing our team and exploring new ways to not just recognize, but also celebrate the unique diversity that makes up our global Fedora contributor community.
Some of my fellow Debian Developers (co-authors) started harassing
my family and I back in 2018 at a time when I lost two family members.
This blog has been written under duress. Normally the best thing to
do with bullies is to ignore them but they are blackmailing me with the
threat that WIPO will publish some insults denouncing me,
destroying my life and trying to push me into the
Debian suicide cluster.
Trigger warning
The Debian online community makes malicious references
to harassment and abuse, deliberately conflating different meanings of
these words to sully the reputations of independent volunteers. Victims
and witnesses to real harassment and abuse may be triggered
by exposure to these word games in the Debian online community.
Background
The misfits have now used Software in the Public Interest, Inc,
an organization that I have no relationship with, to transmit insults
through WIPO.
Some people may think that after more than three decades that I
have been doing voluntary work in ham radio and free, open source software,
this must be some kind of April Fool's Day joke. Sadly it is not.
The case says a lot about the toxic culture of these small-minded
people who are using the trademark to cling onto the coat-tails of
Debian's founders.
It is glaring at us in the list of domains in dispute. While these
misfits spend all their time slinking around in chat channels
jealously sneering at the real developers, I was the only one engaged
in creative thought registering some of the most exciting Debian-inspired
domain names. To prove the point, here is the list of domain names now
in dispute. Given all the effort they put into the debian.community
vendettas, why did none of the misfits spare a minute to think of any of
these names and register them first?
The list of domains is startling but at the same time, it captures
all the most contentious political issues in Debian today.
I feel that I have done the real community a huge service by thinking
ahead and registering these domains before they could fall into the
hands of cybersquatters.
Criminal proceedings in progress
There are now a range of criminal proceedings in progress regarding
the harassment of my family and I.
The outgoing Debian Project Leader has used his final email
newsletter to distribute defamation about police involvement.
This demonstrates the real motive of the WIPO insults is to use
all forms of proceedings concurrently, with as much noise about it as
possible, to cause the maximum stress and psychological harm to victims
such as my family and I and other independent volunteers.
The current harassment through the WIPO process is a violation of
UDRP Rules 15(e) regarding the harassment of the
domain name holder.
The outcome of criminal proceedings may help to test the
evidence submitted by the parties, to fill the deliberate gaps
in the evidence and to give some indication of the real source of
bad faith and previous patterns of harassment against my family and I.
I believe the panel should suspend the current procedure and
wait for the parties to provide details of the criminal proceedings
to the panel.
1.
Expresses respect for all victims of totalitarian and undemocratic regimes in Europe and pays tribute to those who fought against tyranny and oppression;
In point 4, the European Parliament asserts that
constant vigilance is needed to fight undemocratic, xenophobic,
authoritarian and totalitarian ideas and tendencies. Inspired by
this bi-partisan resolution from the European Parliament, I created the
web site Nazi.Compare and started publishing
examples of poor behavior by the vigilantes in free, open source
software communities.
Moreover, 2 April is Carla's birthday. The manner in which rogue
Debianists and toxic people at WIPO demand that I shift my focus to their petty
concerns is another prime example of the way that Debian fascism
(Debianism) is imposing on our families and personal lives.
Carla was born in Chile on the very day that Argentina launched their
doomed invasion of
Las Islas Malvinas / Falkland Islands. Carla's country, Chile,
who share a 4000km land border with Argentina, sided with the British
and allowed British forces to operate from Chilean territory.
Margarita Manterola (marga), who is Argentinian,
banned Carla from food at DebConf, despite the fact that Marga
has attended numerous DebConfs with her husband. Just another example
of how these two-faced people behave.
WIPO, Modern Slavery and Blackmail in Switzerland
The deadline also coincides with the Easter long weekend. While
other people are able to rest on the long weekend, these people are
blackmailing me to focus on my work with Debian, which is a voluntary
activity.
Blackmail is accompanied with a threat of adverse consequences.
In many countries, blackmail is a crime.
Forcing people to work without payment is a crime.
WIPO operates this blackmail with the threat that if I do not
spend Easter reading their insults and sit here working on this response,
they will automatically re-publish insults
and defamation, dragging the name of my family through the mud.
In other words, WIPO are revealing themselves to be a fascist
regime, a lot like those regimes that the European Parliament resolution
is warning us about.
I have already done decades of voluntary work for Debian and free,
open source software and now they force me to work on a public holiday.
The insults misfits submitted through WIPO regurgitate references to
harassment, abuse and 2018, the time when the trial of Cardinal George Pell
was underway, among other things.
Normally, when cases of abuse appear in the news,
the identities of victims, possible victims, witnesses, any other children
who were there and anybody in proximity to the children is obfuscated.
Yet Google, WIPO and Debian seem to be able to do as they please
and spread rumors about harassment and abuse of anonymous victims
in proximity to the volunteer developers.
The WIPO UDRP process makes no reference to how they protect the privacy
of people in proximity to potential cases of abuse.
I contacted various lawyers about the matter, this is an example
of one response from a firm registered with the bar association
in Ireland:
We are a small firm and our resources are quite stretched at this time.
Nonetheless, one of the architects of the cover-up in Melbourne has been
linked to Ireland.
Response being prepared without legal representation
In 2021, my business purchased a legal protection insurance from the
firm Parreaux, Thiebaud & Partners in Switzerland. It turns out this
firm had been operating in Switzerland since 2018 without a license
to sell insurance and without all but one or two staff having a law
license. In other words, from the perspective of the clients, the
Swiss insurance was no better than a ponzi scheme. Even more disturbing,
the Swiss authorities, including the financial regulator FINMA and
the Ordre des Avocats de Genève (Geneva Bar Association)
apparently knew about this since 2021 but didn't close the firm down
until 2023. It is the
Swiss JuristGate affair.
In some countries, like South Africa, home of the outgoing
Debian Project Leader Jonathan Carter, you can pay less than that to
have somebody killed.
No faith in WIPO, the legal panel, conflicts of interest
In the previous WeMakeFedora.org dispute, the ADR Forum
proposed a legal panelist who had a leading role in a trade association
promoting the interests of the complainant.
That particular conflict of interest was very easy to recognize
and the panelist withdrew from the process.
Many of the panelists appear to be associated with companies who
have funded one of the parties and some of them appear to be involved
in groups like the
FSFE Legal Network. At the same time, many of the current
vendettas appear to intersect with both FSFE and Debian at the same time.
Therefore, without being able to determine the extent to which any
particular panelist or WIPO employee is engaged in these other groups,
I do not trust any of them.
Jurisdiction and cultural issues
The WIPO documents specify a jurisdiction for the domain registrar
but the content on the web sites needs to be viewed through the
perspective of different jurisdictions and cultural conventions.
The Debian co-authors today come from a
range of different countries
each having their own legal and cultural expectations about matters such
as copyright, privacy and abuse.
There is a widespread understanding that the free, open source
software community values freedom of expression in the sense of the
first amendment to the US constitution / US Bill of Rights.
When people look at the
Debian Social Contract, which includes the
clause (3) We will not hide problems, there is an expectation that
we have all agreed to collaborate under an American regime of transparency
and free speech about organizational issues.
The role of Debian Project Leader has been performed by people from a
range of different countries where norms differ from one country to the
next. For example, Chris Lamb, who started the current vendetta in 2018,
is from the UK. It has been quite normal for the British press to
publish information about the former Mayor of London trying to help
girlfriends get jobs in the public service. Asking similar questions
about women who won internships in proximity to Chris Lamb feels entirely
compatible with the convention followed in British society.
In other European countries, such as Germany and Switzerland,
there seems to be far more emphasis on protecting the reputations
of those who are party to such affairs such that the whole affair
is often hidden from view. There is a perception that people from
these countries want to have their cake and eat it too. They
demand privacy for themselves but they still lurk on the
debian-private mailing list and chat channels spreading rumors
about the rest of us. They want to download and use the software without
paying for it and they don't even respect the principles of the developers.
The FSFE is even using a name derived from the American FSF, it
is feels like
a case of identity theft,
but at the same time they are snubbing freedom of expression.
Content that appears to be inconvenient for an entirely
German online community is quite valid in an online community claiming to
adhere to an American style of discourse.
Similarity of the domain names
It is clear that most of the domain names are either identical to
the trademark or they contain the trademark.
Total similarity is completely normal and inevitable because the
misfits behind the WIPO insults and I are all collectively co-authors
of the same Debian software that is identified by the trademark.
Some of the names, such as debianproject.org may appear
to be particularly audacious. Nonetheless, I do not expect the
legal panel to be the first to approve such a name. The previous case
D2000-0410 Religious Technology Center v. Freie Zone E. V.
concerned the domain scientologie.org which is totally
identical to the German spelling of the trademark. The case
was decided on the merits of legitimate interests. The
incredible similarity was not a black mark against the choice of
domain name.
It is odd that the misfits have
spent $120,000 on legal cases
to censor domain names but they couldn't think of any of these
names and register them in advance.
Money can buy legal harassment but it seems money can't replace
the creative minds that have abandoned Debian long ago.
Legitimate interests to use the trademark
There are various grounds providing Debian co-authors with a legitimate
interest to use the trademark in a domain name and in other contexts.
Legal counsel representing the misfits have submitted to WIPO
a copy of a previous WIPO censorship decree discussing the
scientologie.org dispute. Therefore, I presume that the
misfits and their legal counsel are aware of the arguments relating
to the scientologie.org verdict
(
WIPO UDRP case D2000-0410).
The outcome in the scientologie.org verdict is that somebody
having a copyright interest in a creative work that shares the name
of a trademark, that person has a legitimate interest in using the
name of the creative work in a domain name and possibly other contexts too.
By submitting the document, they implicitly acknowledge the open questions
from the previous legal panel.
The respondent to the previous dispute was an anonymous non-profit
organization, the Free Software Contributors Association. The
association asserted that some of their members were Debian Developers
wishing to protect their anonymity and privacy. In relation to whether
or not those people are real Debian Developers, the panel wrote:
The Panel confirms that this finding does not imply
that it has taken any view of the ownership of copyright in DEBIAN
software. Indeed, it is unable to do so on the evidence before it.
The panel did not seek to speculate on the names of the authors
contributing to the site but the misfits have been hysterical in
their finger pointing. After stealing that domain, the only thing
they used it for was publishing attack pages. In other words,
they violated UDRP rule 15(e) after the procedure had completed.
These two lines from that panel are significant and as the misfits have
submitted this document in support of their demands, with the help of
legal counsel, we are surprised they have not tried to answer that question
proactively. It appears that they don't care too much about documenting
and protecting the exclusive economic rights of a copyright owner or
the moral rights of an author.
On the distinction between the exclusive economic rights of a copyright
owner, I note that none of us Debian Developers, being the co-authors
of Debian, have ever been asked to assign our rights to any third-party
copyright owner. The misfits have not submitted any evidence purporting
to prove that such an assignment did take place. Therefore, there is no
copyright owner having exclusive economic rights over the Debian software.
By default, the rights rest with the authors who did the work. Despite
having clearly
read the panel's comments, the misfits have not submitted any evidence
claiming that any such party exists with exclusive economic rights
as a copyright owner of the Debian software.
Legitimate interest: a very long history of voluntary contribution
Some of us started doing Debian as a hobby alongside other hobbies
such as amateur radio. One of the early Debian Project Leaders,
Bruce Perens, also notably came to Debian for amateur radio purposes.
I passed the amateur radio exam in 1993,
when I was 14 years of age.
My first years of voluntary activities in amateur radio and free software
were during a time when I was legally a child. I didn't receive any
payment for some of those activities. I offered my time on the basis
that I was gaining skills and helping real communities.
Around the same time, while I was still legally a child, I came to
appreciate the fact that there are some adults who exploit talented and
precocious youngsters by trying to direct the work that is being undertaken
and failing to disclose or share financial benefits.
The Debian Project constitution was originally published on
10 September 1998,
some time later.
The trademark was only registered later on 21 December 1999
Looking at the Scientologie.org UDRP verdict, the panelists
gave some weight to those possessing a copyright interest that predates
the registration of a trademark or a copyright interest arising from
a situation that intersects with the history of the trademark.
Legitimate interest: the Debian license statement
Oddly enough, Debian documents and files in a Debian system refer
to the licenses of the individual packages being distributed. It
was hard to find an actual example of a copyright statement or
license for Debian itself as a collective work.
The
Debian Project constitution of 1998, referred to above,
encourages Software in the Public Interest, Inc to register a
trademark. It says nothing about copyright in the existing body of
work.
Here are the words from the original constitution:
Since Debian has no authority to hold money or property, any donations for the Debian Project must be made to SPI, which manages such affairs.
SPI have made the following undertakings:
1. SPI will hold money, trademarks and other tangible and intangible property and manage other affairs for purposes related to Debian.
So people can donate intangible property like copyright to SPI if they make a personal decision to do so. The constitution did not oblige us to make such donations/assignments.
This situation is well known in open source software development.
Some companies ask their contributors to sign a Contributor License Agreement
or an assignment granting all their rights to a central entity with
exclusive copyright.
Such an assignment can't take place through a majority vote, such an
assignment or transfer of rights to a single entity would require
the unanimous consent of every single author who ever contributed
to Debian. In the case of those authors who are deceased, we would
need to obtain consent from their estates.
Continuing the search for a Debian license,
on the ISO installation media, I found the file
isolinux/f10.txt which contains the very brief text:
COPYRIGHTS AND WARRANTIES
Debian GNU/Linux is Copyright (C) 1993-2016 Software in the Public Interest,
and others.
The Debian GNU/Linux system is freely redistributable. After installation,
the exact distribution terms for each package are described in the
corresponding file /usr/share/doc/<packagename>/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
It asserts that copyright is owned by Software in the Public Interest,
and others. Most of us are individual private volunteers and we
have never personally chosen to grant or assign our copyright interest
to Software in the Public Interest. I became curious about who put
this statement into the ISO image.
Debian is a collective work under the above US copyright law.
The work was initiated in 1993 by Ian Murdock in the United States.
In a Collective work (US), the authors (or co-authors) are selecting works
from third parties and arranging them into the final product, Debian,
a collective work. The decision making process that involves selecting
third party works and the decision making process that involves
arranging the third party works gives rise to the moral rights
of authorship in the Debian collective work.
The “authorship” in a collective work comes from the original selection, coordination, and arrangement of the independent works included in the collective work.
In the Debian world, the independent works are referred to as "upstream" source code. The authors of independent works are referred to as "upstream authors" or just "upstream".
The Debian maintainer guide describes the process of jointly selecting the independent works for inclusion in Debian. In particular, co-authors are required to create a public "Intent To Package" (ITP) report in the bug tracking system (BTS) so that other co-authors can discuss the merits of the selection decision. The requirement to engage in a shared discussion for every selection decision gives rise to joint authorship rights.
Moreover, the person who creates the package importing the independent work into Debian is required to create a manifest describing the inclusion of the independent upstream work. This manifest is the debian/control file. The Debian Policy Manual provides a list of fields in the debian/control files.
Some of these fields are dedicated to the coordination and the arrangement of the independent works within a Debian system.
Coordination of the independent contributions: the package dependency fields describe the relationships between packages that have to be installed together or which conflict with each other. In many cases, when a library package is a dependency for other packages, we have to ensure that the version of the library package in Debian is compatible with the dependent packages. We have a formal process of coordination in this case, the Transition process. Populating the dependency fields in the debian/control file and participating in a Transition process, either as the producer or the consumer of a dependency, are examples of coordination of the independent works from upstream authors.
Here are some examples where I personally engaged in these actions:
The fields Section and Priority impact the arrangement of the contributions from the perspective of the user. The person completing the values in these fields is engaged in the process of arrangement of the contributions in a collective work.
Therefore, the development of Debian includes features of
both a collective work and a work of joint authorship at the same time.
Moreover, due to processes such as library transitions, NMU and our
system of voting on certain decisions, any co-author may influence the
way that other co-authors are integrating the independent upstream works
into Debian. This cross-pollination of ideas and effort is a well known
feature of Debian. In other Linux distributions, the developers are
a little bit more siloed from each other.
Every two years, an official stable release of the Debian software
is released to the public. This process of releasing involves
declaring a version number that corresponds to a particular subset
of the contributions that are in a working state at the time of the
release. Even if a Debian Developer's contributions are obstructed
from inclusion in future releases, or if a Debian Developer commits suicide,
their work is still present in all the past releases that have been
published.
My own contributions are included in a number of these Debian releases
over the years.
This
report finds my name in changelogs and copyright files.
There are 21 pages of results.
Shooting themselves in the foot
To declare that the Debian Developers do not have authorship
rights at all would be incredibly de-motivating.
Future volunteers may be deterred from contributing their
intellectual property and their time.
Legitimate interests: the Debian family fallacy
Debian oligarchs repeatedly tell us that we are all a family.
Harry and Meghan were asked to stop using their
His/Her Royal Highness (HRH) styles.
Harry was banned from
wearing military uniform at the funeral of the late
Queen Elizabeth II. Yet they still have a legitimate interest
in using the family name, Windsor.
If Debian really is a family, and it certainly isn't an employer,
we can all use the family name even if we are not willing to live with
each other in the same castle.
Legitimate interests: the promise of recognition
The misfits behind the WIPO insults do not pay the rest of us anything
for our collaboration in creating the Debian software.
They told us that the only thing we get in return for our creations
is the recognition.
They are now using the debian.org web site and the trademark
to give people negative recognition. This is like bouncing a cheque.
In the circumstances, it seems entirely appropriate for me to follow
through on the promise of recognizing people. The misfits have provided
a list of the domains along with the dates that each domain name was
registered. On the list, the name debian.plus is the first
name registered. debian.plus was registered for the purpose
of delivering on the promise of positive recognition to the
authors and our work.
Debian promises recognition, I take the following quote from
the latest Debian law suit where they admit using the promise of recognition
to lure people into working for free:
64. ... un des avantages importants de travailler pour la communauté Debian est la valeur de sa réputation dans le domaine, à la fois professionellement et dans la communauté. ...
The motivations of the authors also are varied, but the coin that they get paid in is often recognition, acclaim in the peer group, or experience that can be traded in in the work place
you are recognized for your contributions ... Did you ever have a boss who takes credit for your work? Not in Debian.
In short, there is a big emphasis on working for recognition instead of a salary. They gave us the promise of recognition and that gives rise to a legitimate interest in using the trademark in domain names for web sites about our work.
Legitimate interests: promoting my creative efforts
The scientologie.org UDRP verdict makes reference to the
promotion of an author's work.
This point was also emphasized by the legal panel considering
previous Debian disputes. The panel wrote:
Unlike the circumstances in Religious Technology Center
v. Freie Zone E. V, supra the Respondent in the present case is not using
the disputed domain name to disseminate information about its
copyright work.
All the web sites that have been started using these domains
involve the promotion of my creative work in a Debian context.
Several of the domain names have been chosen in
recognition to my own work in specific areas of Debian. For example,
the domains debian.chat,
debian.finance and
debian.video have already been
started with information about my work on software relating to
financial software, chat software and video software, as well as
videos about my work.
Legitimate interest: EU whistleblower directive,
raising workplace health & safety concerns
With this authorization, any person who obtains a copy of the
software is entitled to redistribute it.
The DebianGNULinux.org
domain name was registered to do exactly that, to redistribute
copies of the Debian software. This activity has been authorized.
Remarkably, in one of their claims submitted to another tribunal,
the misfits explicitly describe a web site redistributing Debian
as an outrageous crime, despite the fact the DFSG and the license
statement referred to earlier explicitly authorize redistribution of
genuine copies of Debian GNU/Linux.
Such a flagrant violation of the principles in the DFSG appears
to be bad faith on the part of the complainant.
Legitimate interest: use of the logo is authorized
The page describes two versions of the logo, the open logo
and the restricted use logo.
The page gives a free-for-all license to use the open logo.
The logo I am using on pages about my Debian work is the open logo.
Here is the text of the authorization from the trademark holder:
The Debian Open Use Logo comes in two flavors, with and without “Debian” label.
The Debian Open Use Logo(s) are Copyright (c) 1999 Software in the Public Interest, Inc., and are released under the terms of the GNU Lesser General Public License, version 3 or any later version, or, at your option, of the Creative Commons Attribution-ShareAlike 3.0 Unported License.
Legitimate interest: use of Debian-themed web page style
The Debian web page style is used extensively on third party web sites
run by individual co-authors and volunteers.
At the bottom of every page on the main
www.debian.org
web site there is a link to a dedicated page about the licenses
(authorization) to re-use the theme and content of www.debian.org.
Since 25 January 2012, the new material can be redistributed and/or modified under the terms of the MIT (Expat) License or, at your option, of the GNU General Public License; either version 2 of the License, or (at your option) any later version (the latest version is usually available at https://www.gnu.org/licenses/gpl.html).
Work is in progress to make the older material compliant with the above licenses. Until then, please refer to the following terms of the Open Publication License.
This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, Draft v1.0 or later (you can read our local copy, the latest version is usually available at http://www.opencontent.org/openpub/).
“Debian” and the Debian Logo are trademarks of Software in the Public Interest, Inc.
The complainant publishes the source code for the web site theme.
This makes it easy for anybody empowered by the above license to download
the theme and use it when creating their own site.
At the bottom of every page on Debian.org, they promote
the source code for the web site with a link text
"Web site source code is available".
The misfits have been making gossip against my family and I long before
I registered any Debian-related domain names.
Notably, they use the Debian trademark and the Debian.org web site
to add weight to their vendetta to humiliate volunteers and our families.
They censor, threaten and blackmail anybody who dares to challenge
their vendettas. "We are humiliating Bob this week, you can't talk to him
or you are next".
That is what it looks like when misfits blackmail other volunteers.
Therefore, to respond to the vendettas published on Debian.org
by operating similar web sites containing the name Debian
feels entirely reasonable and proportionate as a right-of-reply
by any co-author.
Bad faith: by the complainant, not me
For a UDRP case to be successful, in addition to proving that there is
similarity to the trademark and if the complainant somehow proves that there
is no legitimate interest whatsoever, the complainant must also prove that
there is bad faith in the use of the domain names.
In this case, I believe the test for legitimate interest has already
been satisfied and therefore, when legitimate interest exists, the panel
does not make any inquiry into whether there is bad faith on the part
of the domain name holder.
Under the UDRP Rule 15(e), it is also vital for the legal panel to consider
whether the complainant themselves is harassing the domain name owner or
acting in bad faith. In other
words, whether the complainant has deceived the panel,
whether a complaint has been brought for the purpose of
harassment or whether the complaint is part of a broader pattern
of harassment against the domain name holder.
Therefore, I simultaneously examine the attacks the complainant
is making against my family and I, demonstrating not only that they are
unjustified but also that by making these attacks, the Debian misfits
themselves are clearly engaging in harassment and bad faith behavior.
Bad faith: no communication before opening the WIPO UDRP procedure
The misfits did not make any attempt to contact me and propose
a solution to the conflict. They unilaterally opened a dispute through
the UDRP.
There have been many opportunities for them to communicate with me
like a human being. They talk about Debian being a "family" but
they pack together like gang rapists to pick off developers one
at a time and attack us.
They are bypassing any normal human communication because they
want to cause the maximum amount of stress. They want
WIPO to publish the name of my family in a negative context more than
they want any of those domains.
In such circumstances, they prove they are committing the act of
harassment under UDRP rule 15(e)
Bad faith: lawyers get the lifejackets, Abraham Raji gets none
In January 2023, I published a
picture of our crew rowing Head of the Yarra. The guy sitting
behind me won the award for Emergency Practitioner of the Year.
He is just the type of person you would want to have around if
somebody went missing in the water. But in all the years we did
rowing, I don't remember anybody going missing.
A few months after I published that photo and
Abraham Raji
disappeared and drowned on the DebConf day trip.
According to the
Wiki page for the day trip,
volunteers participated in a series of activities throughout the day.
To participate in the final activity, the kayak, the volunteers were
expected to pay an extra fee. People not paying the fee would be
left alone to swim like Abraham Raji.
In Australia, we all learn the basic rules of swimming. Never swim
alone is one of those rules. Swim in the marked swimming areas.
Debian people like to reinvent the wheel and find their own way
of doing things. The DebConf organizers are particularly bad at this.
People are constantly bike shedding about the costs of minor things.
They tell the foreigners from poor countries that they have to
pay their own visa fees. They expected the Indians to pay
the supplement for going in a kayak, which comes with a life jacket, or
be left alone.
But according to their own records, they paid over
$120,000 to lawyers to attack my family and I. Paying the
lawyers was more important than providing supervision or life jackets for
victims like Abraham Raji.
Given this vendetta has drained so much of the budget that somebody
was left without a lifejacket and he died, it is clear to me
that this vendetta is brought in bad faith and it violates UDRP rule 15(e).
Bad faith: attacking a volunteer at a time of grief, disrespect
for the sanctity of human life
The complainant admits they began attacking my family and I
in 2018 (evidence: screenshot of doxing messages from Chris Lamb
further below). This was a time when I lost two family members and it was
a disturbing time for my family and I for a range of reasons.
I told fellow collaborators that I couldn't fully commit to some
of my voluntary responsibilities at that time.
(email to Molly de Blanc)
At the same time, one of the issues causing controversy is the
appearance of a Debian suicide cluster or an open source software
suicide cluster. The attempt to minimize attention on individual
suicides also has the effect of minimizing discussion about whether
the combined body of deaths form a cluster. Public health authorities
define three or more suicides as a cluster. The
public health authorities advise that clusters need special attention
to avoid the risk of further deaths.
Moreover, given the way that the Debian deaths intersect with
my own family life, including the unexplained
death of Adrian von Bidder on the day of our wedding,
a possible suicide,
the grief and toxicity associated
with these phenomena have inevitably become intertwined.
This phenomena should be examined from an independent perspective,
with a focus on the issues and not trying to misdirect attention towards
a volunteer who expressed concerns about it. Forcing an individual
volunteer to write about such phenomena under the threat that WIPO
will denounce me is abhorrent.
Given that we already have this unexplained Debian death on the
very day of our wedding, which is a huge scar, how can they possibly be
imposing more scars upon my life with the continued burden of public
harassment on the Debian web site and through WIPO? It is too much and
it has been going on for too long.
Therefore, the bad faith is entirely on the part of those bullies
forcing the matter before WIPO.
Bad faith: psychological torture / cybertorture
In the role the community elected me to perform, I gave people
accurate assessments of the FSFE as an organization. The people
caught doing the wrong thing responded with personal attacks on my
family and on me as an individual.
It is entirely correct for us to scrutinize the functioning of a
group or organization like that. It is wrong for such groups to turn
on an individual volunteer.
Prof Nils Melzer, United Nations Special Rapporteur on Torture and
Other Cruel, Inhuman or Degrading Treatment or Punishment has published
a report on the practices of cybertorture and psychological torture.
An earlier blog post examines the phenomena in Debian.
The insults submitted by the misfits write about excluding
people. We saw similar tactics in the case of the
"hooded men" in Northern Ireland. The obsession with excluding
and isolating people, which comes up frequently in online discussions
between the enforcers, is truly evil.
The defamation and insults created by the Debian misfits focus on
a period when I lost two family members. By making repeated references
to that period in 2018 they are seeking to trigger and exploit feelings
of grief. This is the sort of deliberately cruel behavior envisaged
by the UN special rapporteur.
Given that the misfits used WIPO and the UDRP to transmit documents
targetting a period of grief, this is an example of a complaint brought for
the purposes of harassment in violation of UDRP rule 15(e).
Bad faith: intent to use the domains for vendettas
The misfits provided a copy of a previous UDRP censorship decree
for a domain they seized. After seizing the domain, the misfits
have not used the domain for any original purpose. They are only
using the domain to publish insults and attacks against my family and I.
Therefore, it would be reasonable to assume that any domains censored
by this new UDRP case will also be weaponized against me.
Given that they have already behaved like this before, with their
use of debian.community, it would be no surprise if they
continue that behavior with any other domains they steal. Therefore,
their intention is to harass me, as prohibited by UDRP rule 15(e).
Bad faith: voluntary work intertwined with our lives
The work we do as open source software developers intersects
with many other aspects of our lives.
For example, when we participate in other voluntary groups in
the real world, we often help them with their technology requirements.
The solutions we provide often involve Debian and other free software
products. When misfits start spreading rumors from Debian into social media
networks, this is harmful to other groups where we participate and
at the same time, it is harmful to our own personal lives,
the places where we go to socialize away from our computers,
the places where we go to exercize and so on.
This intrusion on multiple aspects of our lives, both professional
and personal, is not by accident, it has become a deliberate intention
of the rogue leadership figures who engage in publicly
humiliating volunteers.
Therefore, given the impact that public denouncing us has on our
lives, it is harassment and it violates UDRP rule 15(e)
Bad faith: suicide, stigma and tarnishing
WIPO panelists are asked to consider whether the content of the web
sites tarnishes a trademark. There is clearly a lot of stigma around
suicides. It is inevitable that some tarnishing may occur when
suicide is mentioned.
Nonetheless, the panel needs to consider whether tarnishing is the lesser
evil.
The factual revelations of a suicide cluster do run the risk of tarnishing
the Debian trademark, I am not going to dispute that.
Yet the panel can not automatically conclude that tarnishing is
done in bad faith. If the reason for publishing evidence related to a
suicide cluster is in the interest of public health and preventing more
suicides then it looks like tarnishing but it is NOT bad faith.
Given the nature of suicide, there is simply no way to publish
these public health concerns without the counter-accusations of
tarnishing.
In responding to the previous case of UDRP harassment by IBM Red Hat,
in relation to the domain name WeMakeFedora.org,
I made reference to the Holmes and Rahe Stress Scale.
The loss of a family member is one of the highest events on the scale,
between 63 and 100 points. Significant attacks on the business, career
or professional reputation are rated between 39 and 47. It is suggested
that when these events and scores combine, for example, through bad luck
or persistent harassment, overall scores over 300 are highly likely to
have an impact on health. In other words, there is a higher risk of
illness, accident and suicide for people subjected to stress of this
level.
The complainant is clearly aware of these arguments from the prior
WeMakeFedora.org case so their decision to embark upon
a copy-cat case and deliberately submit documents refering to 2018,
the specific time when I lost two family members, appears to be
a reckless and deliberate attempt to knowingly impose more pain on my family
and I. Therefore, it is clearly a violation of UDRP rule 15(e),
harassment and bad faith by those who initiated the procedure.
Bad faith: concealing risks to children
When IBM Red Hat submitted their case in the UDRP, they included as
evidence an example of content from the WeMakeFedora.org
web site. The example included five blog posts and one of those was
a blog that had originally been published by me and then automatically
syndicated by WeMakeFedora.org.
The blog that IBM Red Hat complained about and therefore wanted to
censor was the blog post
Google, FSFE & Child labor.
FSFE is a non-profit puppet organization jointly funded by Google,
IBM Red Hat and other large corporations.
There are a subset of Debian co-authors who are also associated with
FSFE.
As the community had elected me as the FSFE Fellowship representative
and as I had concurrently been a mentor and administrator in programs
like Google Summer of Code (GSoC) and Outreachy, I had an important
role to play documenting the risks to children.
At the same time these risks to children began appearing in the world
of open source software, the criminal procedure against Cardinal George
Pell had been unfolding in Australia. As it turns out, a family member,
some years younger than me, had been in the choir at the time that the
late Cardinal Pell was Archbishop of Melbourne.
I had personally been an officer of the National Union of Students
(Victorian state branch) in 1999. As far as I can tell, I was the most
senior student representative having contact with somebody in the choir
at the very
time that the late Cardinal was in charge. When I saw risks to children
around the open source software world, how could I not express concerns?
I had started doing voluntary work as a GSoC mentor in 2013. Therefore,
I had five years experience of these programs when I came across the
problems in Albania in the latter part of 2017. I used internal channels
to raise concerns about the risk to minors.
Complainants knew my concerns were based on long standing experience
and on personal exposure to these situations. While credible organizations
would have found a way to deal with these matters diplomatically, the
complainants are simultaneously trying to both censor me and discredit
anything I have to say about these risks.
The fact that IBM Red Hat cited the child labor blog in their UDRP
submission shows that is what they were trying to cover up. Their
UDRP complaint was ruled an act of bad faith.
The fact that I had both privately and publicly expressed concerns about
the risk to children and the timing of Debian's UDRP action coincides so
closely with IBM Red Hat makes me feel they are seeking to censor and
undermine exactly the same concerns about risks to children.
Looking at the way the FSFE's child labor program progressed,
we can see that when the program finished, FSFE obfuscated the
full names of the children who did the work. These children clearly
have a copyright interest in the work they created. In other fields
of endeavour we can see children receiving credit for their work
under their full name. For example, look at the Jackson Five,
where
Michael Jackson began performing under his real name from age five.
The French pop singer
Marina Kaye (a stage name) appeared under her
real name Marina Dalmas on France's Got Talent when she was thirteen years old.
Yet the children who wrote code for FSFE are not given credit under
their full names.
Only their first names were published.
The trial of Cardinal Pell never proved whether abuse took place.
What has been confirmed by medical evidence is that one member of the
choir began substance abuse at approximately fourteen years of age.
There are multiple possible explanations for the substance abuse. For
some of the boys, participation is a burden and they never sing again
after graduating from the school.
The choir was associated with the pressure of maintaining a
scholarship at one of Australia's most expensive schools. The FSFE
YH4F program involved the pressure of competing for a financial prize.
When somebody like me with exposure to both of these situations expresses
concerns, why are these organizations so desperate to cover it up?
The internal reports I submitted about harassment of women and
risks to minors in 2017 are contemporaneous evidence of what really
went on in proximity to the Outreachy funding in high risk countries
like Albania. I was often the only mentor to personally witness the
behavior of local men and women in these groups.
In 2013, when the Australian government sought to humiliate
Iranian women and migrants with a video, I loudly resigned my membership
of the party. This was nine years before the rest of the world took a
serious interest in the plight of Iranian women protesting against
a headscarf Code of Conduct. Even more telling, my written concerns
put the mistreatment of these women in the same category as the alleged
abuse in the Catholic church. The concerns were
captured by Crikey.
Given my personal involvement as a witness over many years, my track
record of being right about these things, sometimes well ahead of time
and the track record of organizations trying to silence people who raise
concerns about abuse, the attempts to discredit my testimony about these
matters in proximity to GSoC and Outreachy is itself the act of bad faith,
a violation of UDRP rule 15(e).
Bad faith: companies trying to keep the real abuse reports in-house
In the world of free and open source software, we have the unique
phenomena of corporate employees working side by side with
developers who work for competitors and also the unpaid volunteers.
After the commmunity elected me as the FSFE Fellowship representative
in 2017, I began to receive significantly more detail about wrongdoing
that goes on in the world of free and open source software. It is
understandably surprising and disturbing for some of the larger companies
to discover that these reports about their employees were going to an
external volunteer and not to their in-house human resources department.
It is a useful moment to compare this situation to how it worked
in the institutional abuse crisis. Australia's Royal Commission published
many of the internal documents from the institutions concerned.
One set of meeting minutes from the Archdiocese of Melbourne stands out.
The Personnel Advisory Board (PAB), a group of highly trusted clergy
who assist the Archbishop with the appointment of clergy to different
roles, has realized that their board is too big and they need to create
smaller sub-groups to handle the more sensitive cases.
Father X____ raised the question of how much is told to whom.
Father X____'s name appears frequently as somebody involved as an architect
of the cover-up. His parish web site notes that
he went into retirement in 2016. Coincidentally, that was
the very moment the Royal Commission was seeking answers from
Cardinal Pell.
Miraculously, Father X____ reappeared very briefly in 2023 to give
a sermon at the funeral of a relative in a tiny village that few people
would have heard of outside the state of Victoria. The following month,
three people from that obscure village died in a mysterious mushroom
poisoning that made headlines around the world.
Here is a snippet from the sermon, the man who moved pedophiles not
only from one parish to another but also from one institution to another.
He mentions a family connection with
a former superintendent of An Garda Siochána (the Irish police).
By moving known pedophiles around, Father X____ enabled more abuse
to take place and this resulted in more lives destroyed by overdoses
and suicides.
Those seeking to discredit a former community representative
are acting a lot like the institutions in the abuse crisis.
As the WIPO UDRP guidelines tell us, anything that tarnishes the
brand of Debian or the church has to be censored and covered up.
They are seeking to remove, censor and discredit me simply because people
told me things I wasn't supposed to know. They would have preferred
that some of these issues with women and children were only known
to a select group of people appointed by the companies, just
as the Personnel Advisory Board sought to limit knowledge of certain
matters to the smallest possible sub-committee of clergy.
While the move to keeping information in-house is understandable
and many companies even have an obligation to do so due to
the privacy rights of their employees, it is not acceptable that
they retrospectively punish me for my knowledge of these things. If
punishing me or discrediting me for that role is part of their objective,
they are the ones behaving in bad faith, violating UDRP rule 15(e).
Bad faith should not be alleged against an individual volunteer
Working in IT, our personal reputations for integrity are essential
for us to feed ourselves and support those who depend on us.
A bad faith finding is likely to cause significant harm to a volunteer's
ability to seek employment, obtain credit and enter into insurance contracts.
There have been complaints that WIPO panels have been making bad faith
findings in cases that are ultimately about political speech rather than
integrity of the publisher. This is very dangerous for personal victims
of such findings and those who depend on such victims.
Moreover, using the bad faith verdict arbitrarily cheapens the
meaning of the term bad faith.
It seems incredulous that a vindictive trademark owner can pay
$1,500 to WIPO to make such an attack on a volunteer that will
destroy that person's future and cause significant harm to those
around them.
It is even more abhorrent that they can do such a thing to somebody
who has contributed decades of voluntary service and to somebody suffering
the loss of two family members at a time of grief.
Scrutiny should be turned around on those organizations who are
exploiting our work and then menacing volunteers with the
total loss of our livelihoods.
Bad faith can't be alleged when following a precedent
If a domain name holder has been motivated to register and
use a particular domain name based on the logic of previous UDRP
decisions, it would be very unreasonable to find the domain name
holder is acting in bad faith.
There was widespread discussion of the scientologie.org
verdict last time there were disputes about Debian domain names in 2022.
Based on those discussions and my new awareness of the
logic behind the scientologie.org verdict, I felt that I had
very reasonable grounds to register some Debian domains for the
purpose of promoting my work in Debian and for promoting Debian,
our collective work, as a whole.
Given that I was motivated by the precedent from another WIPO
panel and there are good reasons for me to feel that I have
legitimate interests on the same grounds, as somebody with a copyright
interest, it is entirely unreasonable to accuse me of bad faith.
Looking at the list of open disputes in the
WIPO UDRP case search,
I can see that the list of domain names in dispute only has one
thing in common: they are all owned by one person, me.
It is clear they are not concerned about the content, they are
concerned with attacking the person, me.
Moreover, this ad hominem attack behavior has started before the
registration of the domains and before the complaint. For example,
the defamation statement submitted by the complainant is another
example of an ad hominem attack. The statement is dated 2021,
before all but one of these domains were registered. It shows that the
complainant has a history of making ad hominem attacks with
an intention to harm my family and I.
An ad hominem use of the UDRP process is therefore harassment
by the complainant and a violation of UDRP rule 15(e).
Bad faith: complainant seeking revenge for whistleblowing about bad
faith
Insults submitted by the complainant as evidence show they started
harassing my family and I in 2018.
If we drill down, we find they started this harassment in September
of that year.
In April 2017, the FSFE members elected me as their Fellowship
representative. There is a significant overlap between members of
the FSFE (approximatley 1532 people at the time of the election)
and co-authors of the Debian software.
If you hire an engineer to inspect a used car, you would hope that
they would be able to verify basic things like the authenticity of the
serial number (VIN) on the vehicle chassis. As the elected Fellowship
representative, I had an obligation to report the FSFE was not what
it claims to be.
The money that volunteers and private individuals have contributed
to FSFE over the years is far more than the value of most used
cars. Therefore, in the case of FSFE, there is both evidence
of bad faith and there is quantitative evidence,
the financial reports,
showing us the impact of that bad faith.
The attacks against my family commenced immediately after I published
the evidence of bad faith by FSFE. The email was sent to the LibrePlanet
list on 11 September 2018 and the attacks began about one week
later, as shown by the date of the email from Chris Lamb below
on 20 September 2018.
The attacks against my family and I are a predecessor of this
harassment through the UDRP. It has been a continuous pattern of
harassment over six years now. It appears that this harassment,
of which the UDRP insults are just the latest instalment, is part
of an overall reprisal for the reports I gave the community in
my capacity as the Fellowship representative.
Using the UDRP to insult and harass a volunteer community representative
as a reprisal for performing their duties is clearly an act of
harassment and bad faith as anticipated by UDRP rule 15(e).
Evidence: email from Mirko Bohm: I would like to thank you for your contributions to FSFE and for your commitment not to shy away from asking the difficult questions and calling out the need for change where it exists.
Bad faith: complainant reneges on their own Diversity Statement
The pack adopted the Debian Diversity Statement by a General Resolution in which all the co-authors were invited to vote.
The Diversity Statement begins with the line:
The Debian Project welcomes and encourages participation by everyone.
The insults that they submitted with the complaint, the defamation
statement created by Donald Norwood in the Debian Press Team, contradicts
their own Diversity Statement which was adopted by a General Resolution.
Such a contradiction demonstrates a significant lack of integrity
and their defamation statement should not be taken seriously.
I informed people that I had resigned from some of my voluntary roles
at a time when I lost two family members. Therefore, their behavior
towards my family and I is not just a plain vanilla violation of the
diversity statement, it is an aggravated violation. It is bad faith.
Bad faith: the complainant is gaslighting about authorship and membership
The complainant appears to pivot back and forth between concepts from
copyright law and from the law of associations.
Consider the case when somebody begins contributing to Debian.
There is no such thing as a "New member" process. Rather, it has
historically been called the "New maintainer" process. We can see that
clearly in the
name of the
debian-newmaint mailing list.
The word "maintainer" primarily implies somebody is doing creative work to
select, coordinate and arrange more independent works into Debian.
Then we have the guide for the
New Member process, which was previously known as the New
Maintainer process. In step 3, explained in that page, the new contributors
are asked to agree to the Debian Social Contract,
the Debian Free Software Guidelines and the
Debian Machine Usage Policy. The former is ultimately about our relation
as authors, not as members and the terms under which we license our
work to the rest of the world.
The new maintainer/member guide doesn't ask people to ratify
their adherence to the constitution. The notion of joining an association,
whether it is incorporated or not, is inseparable from consenting to
be governed by and uphold the association's constitution. The
only people who ever ratified the constitution were
86 co-authors
in 1998 (23% of the developers at that time) who wanted to have
a constitution.
Somebody who did not ask to be a member can't be expelled.
Somebody who is not an employee can't be demoted or sacked.
Yet we have seen some of the leadership figures insist on having
these powers over a
series of victims. The title Debian Project Leader
implies just that: to lead, not to give orders.
The insinuation that concepts of expulsions and demotions can
be applied to co-authors is an example of gaslighting.
Copyright law is very clear: co-authors of a work are
equal. Notions of expulsions and demotions violate
the principle of being equal.
The fact that they are knowingly and deliberately trying to obfuscate
our moral rights as co-authors, giving us nothing in exchange
for the status they are taking away, is an aggravating factor
that justifies the finding of harassment and bad faith against
the complainant.
Bad faith: use of an administrative process to extinguish the moral rights and recognition of co authors
The paper notes that the Nazis used administrative law to
frustrate the rights of authors, just as misfits are using a WIPO
administrative process to harass and intimidate a Debian co-author.
Quoting the journal article:
Despite the fact that written IP legislation in Nazi Germany
did not include specific exclusions for Jewish applicants and authors,
in practice, they were excluded by administrative measures alone
rather than legal ordinances.
The misfits frequently use the same language, the word "exclude" comes
up again and again. Harassment, UDRP rule 15(e)
Bad faith: Debian Trademark Policy never ratified
Debian co-authors have never been asked to individually ratify the Debian
Trademark Policy or any similar regulations.
A trademark policy published unilaterally by the trademark owner
can give people authorizations above and
beyond fair use and legitimate interest. On the other hand,
such a policy can not unilaterally erode the default rights to
fair use and legitimate interest.
Hypothetically, the complainant could ask co-authors to
sign some agreement waiving our fair use rights. This may
happen in the context of employment, where those who receive a salary
agree to forego other rights.
Debianists do not pay us a salary and they did not ask us to
individually ratify any agreement waiving our fair use rights.
They have
never tried to do this. The only agreement they ever asked each and
every one of us to individually ratify is our adherence to the
Debian Machine Usage Policy and to the Debian Social Contract.
Therefore, in my role as a co-author, I am not bound by
any restrictions unilaterally imposed upon us by
the Debian Trademark Policy and only the normal rules of
fair use and legitimate interest can be considered in this dispute.
Moreover, it is bad faith by the complainant to simultaneously insist that
they can expel somebody, which is really a nonsense concept in terms
of joint authorship rights, as such rights can't be extinguished
and then insist that the people supposedly expelled will still
remain bound by rules from above that only apply in the context of
being a member of their clique.
Bad faith: complainant reneges on existing authorizations
As noted in the statements on legitimate interest, the
complainant has clearly authorized many of the things they complained
about.
The Debian Social Contract, which states "We will not hide problems",
authorizes discussion of controversial technical, social and ethical
topics. In fact, it is more than an authorization, it encourages
such discussions and publications. Therefore, their complaining
about what is published on these web sites is itself an act of bad faith.
They authorized use of the logo, as discussed, so their complaining
about use of the logo is itself bad faith.
They put the web site theme and content under the open source licenses,
as discussed above, so their complaining about sites with a similar
appearance is itself bad faith.
Overall, for their claim of bad faith to supercede these authorizations,
they would have to demonstrate some extraordinary acts of wrongdoing,
for example, to show that a web site was using the trademark, domain
name and logo to distribute a virus. They provide no evidence of
such wrongdoing.
Bad faith: the complainant's evidence
They submit many boilerplate documents containing copies of
the domain and trademark registrations. On top of that, they
only submit three other documents.
One of those is the copy of a judgment from a previous Debian
dispute. The judgment expresses concern about some specific images on another
web site. The complaint does not provide any examples of those
images or any similar content on any of my own Debian web sites.
Therefore, this judgment can't be extrapolated to content on my
own web sites.
They provide a copy of biographical information about me from
my company web site. This is not published on one of the domains
in dispute so it is not relevant. By providing this, they are insulting
me. Looking at the very first archived copy of an email from
the debian-project mailing list in 1994, we
find that Debian co-authors are using the term
Debian Developer four years before there was a trademark. That is
four years before the Debian Project constitution. The term
Debian Developer is completely valid
for somebody who has done significant creative work over many
decades. In plain English, the term Debian Developer can mean
three things: somebody who possesses the skill of creating
Debian software, somebody who has an authorship interest in
the Debian software and thirdly, but lastly, somebody who is
a member of the clique. Copyright law does not require somebody
to be a member of the clique. I never joined the Debian Project
Unincorporated Association, I have always used the term
Debian Developer first and foremost to describe myself as an author with
moral rights in the creative work. Given that they have taken
this text from a web site that is not even part of the dispute,
I feel the legal panel would be best to avoid getting involved
in this aspect of the dispute.
The third document they provide is a defamation they created
themselves. They are clearly hoping to have WIPO republish
insults and defamation to cause some sort of harm to my
ability to work and feed myself.
They allege that there was some issue of harassment
but do not provide any details. They claim it was in the year
2018, a period when I lost two family members. Their insistence
on twisting a knife in my back at such a time only proves
bad faith on their part.
In various ways, we can see that the document they submitted
is a fraud that has the possibility of deceiving the WIPO
legal panel.
For starters, the harassment began in 2017. Even
the year specified in their evidence is wrong. Therefore,
the evidence they are submitting is a deliberate deception that
tries to invert the story.
Here is the internal report about the harassment. The date is 12
October 2017 so the misfits are clearly lying to the WIPO
legal panel. I have redacted the section that identifies
underage victims.
There you have it. The most senior student representative to have
had contact with a member of the choir in the era of Cardinal Pell has
subsequently arrived in Albania and correctly and discretely raised the
alarm about pimps and pedophiles using funds from Mozilla, IBM Red Hat
and other tech companies to bait their child victims and young women.
It is creepy how the complainants deception about the dates and details
mirrors the case of the
Swiss JuristGate scandal. The
Swiss financial regulator, FINMA, has published a summary
of their decision to shut the rogue firm. In the summary
of the decision, not only does FINMA redact the names of those
responsible for ripping off the customers, FINMA even redacts the dates.
One of the reasons FINMA is redacting the dates is to hide how long
the regulator and the bar association really knew about the scandal.
The hidden dates are examined in more detail in my first
blog post about Juristgate. Here is a screenshot from the FINMA
document showing where the year is obfuscated / redacted:
The FSFE
Fellowship elected me as a community representative in April 2017.
Shortly after that, women in Albania confided in me about the incidents
of harassment. I traveled there again to help organize a MiniDebConf
and Fedora Women's day and in the process, I became a witness to
acts of harassment and a serious possibility of underage abuse.
All of this clearly began in 2017 but the defamation created by
Debian seeks to obfuscate the year and the source of the harassment.
They completely fail to thank me for the effort I made supporting
these women. This was an effort above and beyond what had
been anticipated when I volunteered to speak at the conference
in Albania.
At the time, I had confided in the women that I was watching
these matters very carefully because one of my cousins, who is much
younger than me, had been in the St Patrick's cathedral choir
during the time Cardinal George Pell was Archbishop of Melbourne.
The Pell case was one of the most high profile allegations of abuse
in the Catholic Church. The Royal Commission notes in their
report that of 15,000 victims who contacted them,
the Catholic Church was implicated in far more cases than all the other
religions combined.
In the meantime, Carla had also written about her eating disorder
on her web site. Research estimates that at least thirty percent
of women with these conditions have been victims of harassment or
abuse in childhood.
Various people appeared to resent the fact that women had given
evidence about an (IBM Red Hat) Fedora Ambassador and Mozilla
Tech Speaker to an independent, elected community representative
who was not under any obligation of confidentially to the companies
funding the Albanian groups. In other words, these companies
would have prefered to see the women reporting scandals through
internal company channels.
Shortly after I received this information from women, the FSFE
revised their constitution to
remove their annual elections and
ensure there would never be any other community representative again.
The complete removal of the election and the representative position
proves that this wasn't about any failing on my own part, this was
about the companies behind FSFE wanting to ensure that complaints
about their people wouldn't reach any independent outsider who
might be elected next.
At the end of the process, Mozilla produced a report about the
harassment. I have never been given a copy of the report and
the complainant has not submitted the report either. I don't
feel the complaint should be taken seriously at all unless all
parties, including the legal panel, are granted access to all these
original, contemporaneous documents about the origins of the
harassment and my support for the victims.
Meanwhile, at the very same time as the Cardinal Pell trial
was progressing in Australia, family and friends were shocked to
see mysterious references to abuse circulated on social media.
I don't even have any social media accounts myself so I only
started hearing about these character assassination plots
from witnesses who saw the smears. Cardinal Pell was convicted in December
2018 and a few weeks later, in January 2019, Joerg Jaspert of the
Debian Account Managers team put
mysterious references to abuse in one of our
Debian source code repositories.
One of the findings from the Royal Commission states that
abuse survivors who came forward took an average of 23.9 years to talk about
what happened to them.
Having attended a Catholic school in the same neighborhood and
having multiple connections with fellow alumni and the diocese, it
would not be a surprise for me if any one of the people I know
might reveal themselves to be connected with the scandal at some
point in the future.
Moreover, two of my cousins passed away far too young.
It is so shocking for me to see how these dirty men are playing these
games with the subject of abuse.
At the time that Joerg Jaspert started making these privacy
violations, he was on the school council at Dalbergschule in Fulda, Germany.
Local magazines published a photo of him in a Debian t-shirt
with other parents Claudia Beck and Ina Riechert.
How can the other parents and staff trust this dirty man with
any sensitive topics when he runs around spreading gossip about abuse
in the debian-private world?
Given that background, I find it abhorrent that these silly
people claim to be victims of abuse when what really happened
is they got caught doing the wrong thing. By claiming to be
victims of harassment and abuse, by hijacking and distorting
the language of sexual misconduct they are asking us to exhibit the same
sympathy for long-distance peeping toms at Google as we would for those
15,000 child victims.
Here is another example of Debianists pretending to be
part of the sexual crimes detective unit and circulating
gossip as if it was truth. The email is written by Russell Coker, a
Debian Developer in Australia, half way around the world from
where the rumors started in Berlin. How could he write such
forceful words about Dr Appelbaum when it is something he had no way to see?
This shows how Debianists use their titles and their trademark
to make stuff up and then give weight to defamation.
This type of rogue behavior makes it even harder
for the community to know when real victims take the difficult step
of coming forward with real reports of abuse.
Bad faith: deliberately conflating different types of harassment and abuse
The complainant frequently raises concerns about "harassment"
and "abuse" whenever somebody asks a question they don't want to reply
to.
Yet it doesn't stop there.
Not only do they claim to be victims of "harassment" and "abuse",
they deliberately seek to conflate different meanings of these words.
It works a bit like the game of Chinese Whispers.
The classic example was the lynching of Dr Jacob Appelbaum.
One person posted messages about "harassment". Somebody else who wasn't
actually there extrapolated that into "sexual harassment". Then another
person who was all the other way over the other side of the world in
Australia forcefully writes that it was a "rape".
The word "abuse" is used in much the same way. Somebody asks
a question about the bank account. The question is disparaged as
an unqualified example of "abuse". Later, somebody adds a prefix,
people mention "sexual abuse". But there is nothing sexual about
asking why somebody's girlfriend got paid to do work that other
volunteers do for free. We saw them using this word game in
relation to Prof Eben Moglen recently.
Not only are they trying to defame the person asking a serious
question but we also have to remember that when people try to
portray themselves as victims of "abuse", they are siphoning off a little bit
of credibility from the real victims, like those incredibly young boys
and girls who made complaints about institutional abuse. The pretend
victims and their antics dilute the credibility of the real victims.
Most healthy people are turned off by discussions like this. Yet
there is a subculture around Debian, a subgroup of volunteers who appear
to take some voyeuristic interest in making these word games with references
to abuse, the type of thing we see in the blog post by Matthew Garrett.
Just how did Garrett become an expert on abuse?
These comments about the phenomena may appear quite strong and
defamatory at first glance but the evidence is already public. Have
a look at the controversy about the package with the name "weboob".
According to reports, the source code is laced with crude references
to women. The package was
discussed on debian-private. Quite a few Debian men,
like Axel Beckert, a system administrator at the ETH Zurich university,
defended the package during his working hours.
Subject: Re: weboob package
Date: Fri, 13 Jul 2018 14:29:58 +0200
From: Axel Beckert <abe@debian.org>
Organization: The Debian Project
To: debian-private@lists.debian.org
Hi,
Jonathan Dowland wrote:
> Yesterday I stumbled across the "weboob" package for the first time,
> which includes a slew of binaries with names similar to the following:
[...]
So what? I don't see any problem with that. (And I don't see why
there's a thread on debian-private about it.)
Regards, Axel
--
,''`. | Axel Beckert <abe@debian.org>, https://people.debian.org/~abe/
: :' : | Debian Develoober, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bad faith: timing of harassment
In each case, we can see that one of the Debian oligarchs has
engaged in some form of behavior that involves bullying or harassing
a volunteer and the disclosures about bullying have only happened
subsequent to that.
The vendettas began in September 2018. The complainant has submitted
their case of debian.community and we can see that the domain
name debian.community was only registered in October 2019,
more than 13 months after the Debian Project Leader started spreading
gossip about multiple volunteers.
In April 2021, I
incorporated a new company to promote
my work. In November 2021, the misfits began distributing their
defamation statement about my family and I as a reprisal. It appears
the misfits are jealous that I could start my own company and they wanted to
destroy it. In Australia, we call this the
Tall Poppy Syndrome.
In June 2021, one of the women was caught trying to start rumors about me
having a relationship with a female intern. The same woman was caught
again trying to start rumors in the same chat channel in July 2022.
In March 2023, I created a web site
Outreachy.Dating with proof that the rumors are false.
I did not spontaneously decide to go and create the
Outreachy.Dating web site. The
site only came into existence as a right of reply to the pre-existing
campaign of gossip against my interns, my family and I.
As already described in a previous section, when we agreed to
create Debian together, we agreed to uphold the Debian Social Contract,
which includes the commitment 3. We won't hide problems.
In 2018 and 2019, oligarchs started hiding the blogs of some co-authors.
The same phenomena occurred in the Fedora Linux community. I have
only had to register domain names like
Debian.News and
WeMakeFedora.org in response to the censorship of some blogs.
I did not just wake up one day and spontaneously decide to create
these domain names, I was motivated to do so because the censors
violated our existing rules of engagement, the Debian Social Contract
and the Fedora Foundations.
Bad faith: Debian's violent history of intolerance
Despite all the grand statements about the Code of Conduct, Respect
and Diversity, the Debian people are highly intolerant.
It has always been this way and there is plenty of evidence.
Consider 2006, the violent expulsion of Ted Walther from DebConf6 dinner
in Mexico. Somebody started a rumor that his dinner guest was a prostitute.
Nobody checked the facts. People physically pushed him out the door and
nearly threw him down the steps.
Instead of spending $120,000 on lawyers, they could have simply
apologized to my family for violating our privacy. But they are paying
all this money to rewrite history. They are paying the lawers all this money
to insist that the petty little word choice issues that their small minds are
preoccupied with are more significant than things like the death of
my father.
Bad faith: blackmailing people to disclose personal and private information
Whenever people come across the Debian smearing campaign through
social media and they ask me about the rumors of harassment and abuse,
the first things that come to mind are those cases that arose at
the time. The poor behavior I witnessed towards women from Albania,
Carla's eating disorder and the prosecution of Cardinal George Pell.
Other volunteers have made similar complaints about being blackmailed
to make public statements and disclose things about themselves.
Kuhn: As such, I'm outing myself here first (primarily) to disarm his ability to use what he knows about my sexual orientation against me.
In 2019, we saw that Dr Norbert Preining was blackmailed to
write a self-deprecating forced confession on a public mailing list.
When I saw that Dr Preining and I had been subject to similar
blackmail tactics, I felt that I was being expected to make
a similar public statement about matters that belong in private.
In the case of Bradley Kuhn, his disclosures relate to himself.
In my own case, in all cases of harassment and abuse where I have
been a witness, it is unthinkable that I should be forced by these
rumors to make disclosures about other people.
Therefore, when I published the Mozilla examples above, I partially
redacted them to avoid revealing the names of underage open source
software victims.
Nonetheless, I didn't voluntarily choose to publish responses
to gossip about abuse. They are using the WIPO UDRP to blackmail
me to publish comments about abuse cases. Therefore, they
are violating UDRP rule 15(e).
Bad faith: destroying our portfolio of work
In some industries, it is common for practitioners to carry
a portfolio of their work. For example, photographers, architects
and similar professionals often rely on such a portfolio to show
potential clients what they are capable of.
In computing, prospective employers and clients look at the
portfolio of our work in Debian and other free software projects.
Replacing that portfolio with insults and defamation is akin to setting the
portfolio on fire.
Once again, this appears to be the intention of the misfits behind
the complaint. By publishing attacks on my family and demanding
a verdict of bad faith, they are trying to further undermine the credit
I deserve for decades of work involving free and open source software.
It is harassment in violation of UDRP Rule 15(e).
Bad faith: how many Debian Developers really committed suicide?
There are 972 Debian Developers listed with the status
"Debian Developer, uploading". These are people considered to be active.
When people resign/retire, their status is changed to "Emeritus".
There are 449 Debian Developers with status Emeritus.
The status "Removed" is distinct from the status "Emeritus".
There are 272 Debian Developers with status "Removed". This list
includes people who have died, it includes victims who have been
disappeared and it includes people who have failed to respond
to any attempts to communicate. Some of these people may have been
participating under a fake identity. Some of them may have become
fed up with the politics and walked away without saying goodbye.
Some of these 272 people that we can't account for may have joined
the suicide cluster.
With or without a note, in this list of 272 people "Removed",
there will be many more we don't know about because their families
would never think to tell us.
How many of these 272 vanished after some secret humiliation on
the debian-private mailing list?
How many bloggers have committed suicide after WIPO denounced
them with accusations of bad faith?
Bad faith: deceiving the previous WIPO panel
The misfits have clearly deceived the previous WIPO panel on certain
issues. One of those issues is their claim that Albanian women
paid to travel to Brazil were junior female developers.
I was a mentor and administrator in both the Google Summer of
Code and Outreachy programs over a number of years from 2013 to 2018.
In that role, I interacted with many of the prospective interns,
both male and female.
I was involved in creating tasks that we asked the applicants to
perform to test their skills and demonstrate their motivation
during the selection process
for these internships. I observed the effort that each applicant made,
whether they were male or female.
There were definitely women who did a very high standard of work.
However, there were other women who did not do any software development
and we can see now in hindsight that some of those women still haven't
done any software development despite hanging around the open source
communities for almost a decade. Therefore, the claim that every woman
was a junior female developer was not true. Some women
were junior female developers, the rest we could not refer to with
the term developer.
We can see that the panel was deceived about the origins of
references to branding in the nether regions. This controversy, which
was mentioned in the panel's finding against another domain, is
rooted in the manner in which the misfits created rogue commits in
source code repositories on the anniversary of our wedding.
Specifically, we completed a civil wedding on 23 September 2010
and then we completed the religious ceremony a few months later
on 17 April 2011.
Here is the civil wedding certificate:
Here we can see the rogue commit in the Debian keyring repository,
on the date of the civil wedding, overlaid with the photo of genital
branding from NXIVM.
Given the way this extreme harassment simultaneously intrudes
on both my professional life and my family life, I find these
images even more horrific than they were for the WIPO panel.
Nonetheless, the images of genital branding are as relevant
as they are horrific when you consider the deliberate way these
misfits impose on our lives and our reputations.
Here is the date of the religious ceremony on my wedding ring,
alongside the tombstone of Adrian von Bidder, secretary of Debian.ch
who died in what appears to be a possible suicide on exactly the same day,
17 April 2011:
What an incredibly toxic culture the Debian misfits are trying to hide
with this WIPO UDRP vendetta.
The misfits have made multiple intrusions in the lives of volunteers.
While the scars are not identical, the mentality behind those scars is
much the same. In both Debian and NXIVM, some of the people feel they
have a sense of entitlement to impose upon all aspects of our lives and
our future, whether it is through branding, through gossip or through
demanding that WIPO denounces individual volunteers.
Bad faith: using WIPO and an Albanian gangmaster to defame me
I previously documented how I was a witness to acts of
harassment and the risks to underage participants by two
Albanian men. I attached the emails showing how this was
raised through internal channels at Mozilla.
When Chris Lamb decided to attack me on our wedding anniversary,
he actually used Elio Qoshi, the Albanian bringing a sixteen year old
girlfriend to tech conferences, to distribute the messages about
the vendetta.
At the time, I was with one of the victims. Women who had worked
with me personally had been surprised to see Lamb colluding with
these Albanian gangmasters. I took a photo of the message that
the Albanian forwarded from Lamb to the phones of female victims:
It is an extraordinary example of corruption. When I saw
Chris Lamb colluding with Elio Qoshi to denounce me at such a
painful time for my family, I couldn't help thinking of men like
Jimmy Saville and Rolf Harris collaborating in their
crimes.
Chris Lamb: You are well-aware that I
have been nothing but scrupulous and gentlemanly with regards to your
personal privacy and thus ...
The dishonesty of these misfits is as extraordinary as the
intrusion into the family lives of volunteers.
As Debian is an operating system, it is relied upon as the foundation
for so many other things that people do with their computers both
in industry and in private. In other words, people put a lot of trust
in the operating system but we can't trust the people making it.
Here we have caught the then leader of Debian using a common
garden variety Albanian pimp to spread rumors about a long standing
volunteer and also publicly lying about the matter.
Now these dirty little men aspire to exploiting a WIPO panel
in the same way they used this Albanian gangmaster to denounce
my family and I on the anniversary of our wedding. As mentioned
earlier, the deadline set by WIPO was Carla's birthday.
from Fedora Project Leader Matthew Miller, on behalf of the Fedora Council
First, a personal note! As you may have seen, I was out sick with Covid for a month after getting home from our annual Council face-to-face meeting. It’s not been fun — some respiratory symptoms, but primarily, overwhelming fatigue. Somewhat ironically, the timing suggests that I managed to avoid catching anything at FOSDEM itself (where I wore a mask most of the time), or at the Council meeting, but rather on the plane or in the airport on the way back. Although emergency measures have been lifted, there really is still a pandemic going on. Be careful, everyone, especially when traveling! In any case, I’m back to myself now, and am excited for Fedora’s next big steps.
The Story so Far
So! I’ve been talking about “Strategy 2028” for a while — we started this effort seriously about a year ago. If you’re just joining in, or want a refresher, Fedora Strategy 2028: a topic index for our planning process is a great place to start. I won’t rehash all of that here.
The important thing is: 2023 was kind of a hard year, and although we made some progress, we lost momentum. The Council hackfest helped get things back on track, and we’re moving forward now. We’re not making any fundamental changes, but we are restructuring how we present things — and we’re moving on from theory to practical work.
A New Presentation
Over the last year, we got feedback from many people who felt that the organization into Themes and Focus Areas was overwhelming and confusing. It felt really big, maybe too much, and hard to know where one might fit in.
After some discussion, we decided that we could better present our various objectives as they align with something we’re all already very familiar with: Fedora’s “four foundations”: Freedom, Friends, Features, and First. The objectives we’ve talked about over the past year aren’t going away, but this gives us an easier way to organize and prioritize them over the next few years.
What Else?
Even with a big and ambitious plan, we left some important ideas behind. For example, we want to better tell our Fedora stories (both inside and outside the project), and we want work to improve distribution security. We’re not immediately adding planned effort on these, but our new framing around the Foundations gives us more room to add those things as needed.
Our project has amazing, passionate people who have done amazing things for Fedora and for the world of community-built, free and open source software in general. We should do more to celebrate them, to give everyone the recognition they deserve. We should show new and potential contributors the incredible things we’ve done and the exciting things we’re doing — and what it means to be part of our community.
The recent xz exploit relied on long-term, persistent social engineering within an open source project, along with a very sophisticated technical attack. A long discussion on the devel mailing list shows that we have many ideas for how we can make Fedora more resilient against such attacks as a project, and Fedora Linux safer as an operating system. Initiatives to work on these improvements may end up under a different umbrella, but will certainly have some interconnection.
As we go through the next five years, don’t be surprised to see us add Community Initiatives focused on these things — and others, as they emerge.
And then, there’s AI
We’ve all heard a lot about various “large language model” chatbots, and about image and even video creation. There is obviously a lot of hype around AI — and inevitably, over-the-top nonsense. We’re not really “just five years away” from actual generalized Artificial Intelligence. This isn’t the start of Skynet from The Terminator movies. Human creativity isn’t being replaced, and I don’t think all programmers will end up as “prompt engineers”.
However, there is something real here.
Advances in accelerated hardware and machine-learning software have unlocked possibilities which were imagined last century, but which were not practical at the time. When the dust settles around the hyperbole, I believe we’ll still be left with something significant, powerful.
In addition to the big showy LLM-based tools for chat and code generation, these advances have brought big jumps for more tailored tasks: for translation, file search, home automation, and especially for accessibility (already a key part of our strategy). For example, open source speech synthesis has long lagged behind proprietary options. Now, what we have in Fedora is not even close to the realism, nuance, and flexibility of AI-generated speech.
Right now, most of all this is proprietary. It’s corporate-owned closed models trained with hidden data, largely running on hardware without open source drivers. If we ignore this, we’re going to be left behind — not just Fedora, but free and open source software entirely. On the other hand, we can take a leadership position, and build a future where AI belongs to all of us.
The Guiding Star for Strategy 2028 is about growing our contributor base. We can make Fedora Linux the best community platform for AI, and in doing so, open a new frontier of contribution and community potential.
This won’t be easy. We have a lot of basic work on platform fundamentals. That’s drivers and tooling, packages and containers, and even new ways of distributing Fedora software. We also need to improve developer experience — for example, it’d be nice to have Podman Desktop as part of Fedora, with easy paths to getting started.
We can use AI/ML as part of making the Fedora Linux OS. New tools could help with package automation and bug triage. They could note anomalies in test results and logs, maybe even help identify potential security issues. We can also create infrastructure-level features for our users. For example, package update descriptions aren’t usually very meaningful. We could automatically generate concise summaries of what’s new in each system update — not just for each package, but highlighting what’s important in the whole set, including upstream change information as well.
At the same time, we need to work with the rest of the free and open source world to create labels for AI technology which aligns with our values. We need polices on what we allow, and on what we encourage. We may even need to fight for legal frameworks friendly to community-built software.
Finally, of course, we can provide models in the OS. This includes accessibility tooling, which can benefit everyone: imagine an all-local voice assistant that doesn’t send your conversations to some big datacenter or try to sell you things while simultaneously selling your personal data. We could also include tools that make it easier to find help, features to simplify system administration tasks, and interfaces to better organize your documents and media — all within your control, all running on a free and open source software stack.
We’re just getting started here (with, for example, Pytorch coming in Fedora Linux 40 1, CPU-only — for now). There will be more exciting things coming soon.
Next Steps
The next post will be the high-level view of Strategy 2028, updated from this new perspective.
The Council’s next immediate step is to identify Executive Sponsors and leaders for each Focus Area under the broad umbrellas of our Four Foundations. Then, we’ll plan and schedule concrete outputs and practical activities in each area. For larger efforts, we expect to launch Community Initiatives, but much of the work will be organized as smaller projects under each focus area banner. Expect more announcements soon as we build this out!
Ahh, it's that beautiful spontaneous time of year. A major public security incident has occured
in opensource. All of the epidemiologist's of 2020 suddenly emerge from their chrysalis once more
as a beautiful incarnation of a security expert. The hot takes flow more freely than cocaine at
a Liberal party event. My share
portfolio doubled in value due to taking a long position
on popcorn futures.
It's now been nearly 2 weeks since this glorious event, and the hot takes have started to settle.
Some of these include, but are not limited to:
The original maintainer burnt out, so we should pay maintainers through some kind of sovereign fund (but don't say tax, that's a bad word).
Automake should be shot into the sun because it's so easy to hide backdoors in it.
There need to be more code reviewers in opensource, that would have caught it.
We have normalised abuse in opensource, so no alarms were raised when sock puppet accounts abused people.
C is bad, so we should all use Rust, even though I'm pretty sure we could just stuff unlabeled binaries into Rust just as easily.
That we need more regulation of opensource projects.
Systemd was the cause of the issue since it was linked for sd-notify (and the documentation of how to do this with a unix socket is a one line footnote which no one can find forcing developers to link to libsystemd in the first place), meaning we should renew calls that systemd is an bad.
The clownshoes award certainly goes to this take though
Somehow the redis license change caused this and was a warning ahead of the XZ incident?
Or my favourite, absolutely nuclear take:
GPG would have prevented this by having the new maintainers ID verified by keysigning parties.
But I realised I have my own blog. So it's time for me to post my hot take.
🔥
Our industry is so immature, that people think there is one magic root cause that can be fixed, rather
than admit there are multiple contributing factors.
Incidents like XZ don't happen due to a single cause. They are a series of failures that range from
social to technical, and this combination of factors lead to the events that transpired.
And yet, we reward people who stand up and yell their single hot take, as though if this one persons
emotional outburst was accepted universally we would resolve all problems and our world would leap ahead
in time by decades.
We reward this thinking because it's easy. It's a clear, simple and emotional message that cuts through.
(I'm sure it does good things for the authors ego as well when clicks flow).
But our world isn't simple. There isn't one magic cure.
As an industry we need to stop looking for root causes.
We need to look at all the contributing social and technical factors, and address them all even if
they are just incremental steps. Because as we improve each of these small parts, the whole of
opensource improves.
Except GPG. That key signing party goop is just copium, and wouldn't solve anything.
It’s been a few days since my first entry in this series. For the most part, things have been going quite smoothly. I have to say, I am liking KDE Plasma Workspaces 6 much better than previous releases (which I dabbled with but admittedly did not spend a significant amount of time using). The majority of what I want to do here Just Works. This should probably not come as a surprise to me, but I’ve been burned before when jumping desktops.
I suppose that should really be my first distinct note here: the transition from GNOME Desktop to KDE Plasma Workspaces has been minimally painful. No matter what, there will always be some degree of muscle memory that needs to be relearned when changing working environments. It’s as true going from GNOME to KDE as it is from Windows to Mac, Mac to ChromeOS and any other major shift. That said, the Fedora Change that prompted this investigation is specifically about the possibility of changing the desktop environment of Fedora Workstation over to using KDE Plasma Workspaces and away from GNOME. As such, I will be keeping in mind some of the larger differences that users would face in such a transition.
Getting fully hooked up
The first few days of this experience, I spent all of my time directly at my laptop, rather than at my usual monitor-and-keyboard setup. This was because I didn’t want to taint my initial experience with potential hardware-specific headaches. My main setup involves a very large 21:9 aspect monitor, an HDMI surround sound receiver and a USB stereo/mic headset connected via a temperamental USB 3.2/Thunderbolt hub and the cheapest USB A/B switch imaginable (I share these peripherals with an overpowered gaming PC). So when I put aside my usual daily driver and plugged my Thinkpad into the USB-C hub, I was prepared for the worst. At the best of times, Fedora has been… touchy about working with these devices.
Let’s start with the good bits: When I first connected the laptop to my docking station, I was immediately greeted by an on-screen display asking me how I wanted to handle the new monitor. Rather than just making a guess between cloning or spanning the desktop, it gave me an easy and visual prompt to do so. Unfortunately, I don’t have a screenshot of this, as after the first time it seems that the system “remembers” the devices and puts them back the way I had them. This is absolutely desirable for the user, but as a reviewer it makes it harder to show it off. (EDIT: After initial publication, I was informed of the meta-P shortcut which allowed me to grab this screenshot)
Something else that I liked about the multi-monitor support was the way that the virtual desktop space on the taskbar automatically expanded to include the contents from both screens. It’s a simple thing, but I found that it made it really easy to tell at a glance which desktop I had particular applications running on.
All in all, I want to be clear here: the majority of my experience with KDE Plasma Workspaces has been absolutely fine. So many things work the same (or close enough) to how they work in GNOME that the transition has actually been much easier than I expected. the biggest workflow changes I’ve encountered are related to keyboard shortcuts, but I’m not going to belabor that, having discussed it in the first entry. The one additional keyboard-shortcut complaint I will make is this: using the “meta” key and typing an application name has a strange behavior that gets in my way. It almost behaves identically to GNOME; I tap “meta” and start typing and then hit enter to proceed. But the issue I have with KDE is this: I’m a fast typist and the KDE prompt doesn’t accept <enter> until the visual effect of opening the menu completes. This baffles me, as it accepts all of the other keys. So my muscle memory to launch a terminal by quickly tapping “meta”, typing “term” and hitting enter doesn’t actually launch the terminal. It leaves me at the menu with konsole sitting there. When I hit enter after the animation completes, it works fine. So while the behavior isn’t wrong, per se, it’s frustrating. The fact that it accepts the other characters makes me think this was a deliberate choice that I don’t understand.
There have been a few other issues, mostly around hardware support. I want to be clear: I’m fully aware that hardware is hard. One issue in particular that has gotten in the way is support for USB and HDMI sound devices in KDE Plasma. I don’t know if it’s specifically my esoteric hardware or a more general problem, but it has been very hard to get KDE to use the correct inputs and outputs. In the case of the HDMI audio receiver, I still haven’t been able to get KDE to present it as an output option in the control panel. It connects to the receiver and treats it as a very basic 720p video output device, but it just won’t recognize it as an audio output device. My USB stereo headset with mic has also been more headache than headset: after much trial and error, I’ve managed to identify the right output to send stereo output to it, but no matter what I have fiddled with, it does not recognize the microphone.
More issues on the hardware front are related to having two webcam devices available. KDE properly detects both the built-in camera on the laptop as well as the external webcam I have clipped to the top of my main monitor, but it seems to have difficulty switching between them. I’m not yet 100% sure how much of this is a KDE problem and how much a Firefox problem, but it is frustrating. Sometimes I’ll select my external webcam and it will still be taking input from the built-in camera. Also, it seems to always show two entries for both devices. I need to do more digging here, but I anticipate that I’ll be filing a bug report once I gather enough data.
Odds and Ends
I have mixed feelings about KDE’s clipboard applet in the toolbar. On the one hand, I can certainly see the convenience of digging into the clipboard history, particularly if you accidentally drag-select something and replace the clipboard copy you intended to keep. On the other hand, as a heavy user of Bitwarden who regularly copies passwords1 out of the wallet and into other applications, the fact that all of the clipboard contents are easily viewable in plaintext to anyone walking by if I forget to lock my screen for a few seconds is quite alarming. I’m pretty sure I’ll either have to disable this applet or build a habit of clearing it any time I copy a password. Probably the former, as I don’t like the fact that I have to call up and make the plaintext visible first in order to delete it without clearing the entire history anyway.
Conclusion
This will probably seem odd after a post that mostly contained complaints and nitpicks, but I want to reiterate: my experience over the last several days has actually been quite good. When dealing with a computer, I consider “it was boring” to be the highest of praise. Using KDE has not been a life-altering experience. It has been a stable, comfortable environment in which to get work done. Have I experienced some issues? Absolutely. None of them are deal-breakers, though the audio issues are fairly annoying. My time in the Fedora Project has shown me that hardware issues inevitably get fixed once they are noticed, so I’m not overly worried.
As for me? I’m going to stick around in KDE for a while and see how things play out. If you’re reading this and you’re curious, I’ll happily direct you to the Fedora KDE Spin for the Live ISO or the Kinoite installer if, like me, you enjoy an atomic update environment. Make sure to select “Show Beta downloads” to get Plasma 6!
I generate high-entropy, unique random passwords for everything. Don’t you? ︎
Josh and Kurt talk about a new FCC program to provide a cybersecurity certification mark. Similar to other consumer safety marks such as UL or CE. We also tie this conversation into GrapheneOS, and what trying to claim a consumer device is secure really means. Some of our compute devices have an infinite number of possible states. It’s a really weird and hard problem.
Hello folks! I’m coming to you live from a very wet and windy Ireland. April showers is certainly a thing, but this kind of rain is even giving the typical Irish weather a run for its money! I hope you all have had a good (and drier) week so far and enjoy your weekend, and if you would like some weekend reading, weekend bug fixing, or even a weekend proposal writing session, read on for the links and information you need to do just that
Flock to Fedora
The call for papers for our annual contributor conference, Flock to Fedora, is now open until April 21st. Check out the cfp page for details on the tracks and themes of this years conference, plus information on travel subsidies and how to contact event staff if you need help.
Fedora Linux 40
Important Dates
Currently in Final Freeze
Thursday, April 11th @ 1700 UTC – Fedora Linux 40 Go/No-Go Meeting
Tuesday, April 16th – Current Release Target Date (this will depend on the outcome of the Go/No-Go meeting)
Help Wanted
There are a number of blocker bugs open against F40 at the moment, both proposed and accepted. If you could spare some time to visit the blocker bugs app and reproduce some of the bugs to validate if they are blocking bugs or not, and/or even propose a fix for a bug listed, that would be hugely appreciated. A summary of the current F40 bugs can be found on this email with links to each too.
Fedora Linux 41
Change proposals are welcome for F41, and even F42 (and F43 if you’re that prepared!). The first deadline is 19th June if your change requires any infrastructure changes, and 26th June if it is a system-wide change. Self-contained changes may be submitted until 16th July. Those dates might seem far off, but please do have your changes in Rawhide as early as possible as this impacts a lot of the build and release folks (QA, rel-eng, etc) so getting the work proposed, approved and into development as early as possible is strongly recommended. Below is a list of changes proposed, awaiting FESCo decision and already accepted for F41.
An update on the Git Forge Evaluation has been published by the Fedora Council. Please have a read on discussion.fpo or on the community blog.
The CommOps Team is rebooting! Read about the newly (re)formed team on their blog post and find out how to get involved and join the team.
Help Wanted
Lots of Test Days! Check them out on the QA calendar in fedocal for component-specific days. Help is always greatly appreciated.We also have some packages needing some new maintainers and others needing reviews. See below links to adopt and review packages!
KDE had a feature a lot of people didn’t know about. You could run a command when a notification triggered. The feature wasn’t very well documented and nobody really blogged about it.
However with the release of KDE Plasma 6, the feature was removed. I learned about it by accident, as it is tracked by Bug #481069. I really need the feature and I re-implemented it in KDE Plasma 6. I will be available in KDE Plasma 6.1 and KDE Frameworks 6.1.
KDE: Run a command
Text-to-Speech for calendar events
I’m using the “Run a command” feature for calendar events. Normally you get a popup notification. The popup notification is small and pop up where all of them are shown. When I’m concentrated and working on some code I simply miss them. If I play a game, I miss them.
The solution for me is to use a Text to Speech (TTS) Engine. I’ve setup speech-dispatcher with piper-tts on my system. When an a reminder triggers it says: “Andreas, you have an appointment in 10 minutes: Samba Meeting”.
For my new job, I (annoyingly) have to use a silly MacBook. For everything else, I have a nice, beautiful desktop running Fedora.
I looked into KVMs to share my monitor and keyboard between the two computers, but couldn't really find something reasonably priced and functional.
Synergy/Barrier/InputLeap for keyboard sharing
I have used Synergy before to share keyboard and mouse between Linux computers, and this was already a good step. There is a fork for Synergy on Linux called Barrier, which now has been forked again to InputLeap. It also allows copy & paste between systems.
This brought me half to where I wanted to be, but I was still restricted to the tiny laptop screen on the Mac.
DDC monitor input source switching
Both of my monitors are connected via DisplayPort to my desktop. I now
connected the right monitor also via HDMI to the Mac. This already
allowed me to easily switch between the input sources with the monitor's
on-screen menu.
While researching a new monitor, which has a build in KVM, but only comes with software for Mac & Windows, I found out that you can control most monitor functionality via DCC.
This includes things like brightness, contrast, rotation, and most importantly the input source.
For Linux, you can use ddcutil and your window manager keyboard shortcut settings. For me, it is these two commands, your monitor and sources may vary.
On OS X you can use BetterDisplay, this is a pretty nifty tool to control all kinds of aspects of your display, definitely worth a look. It also supports keyboard shortcuts to change input sources.
There you go, easy-peasy and for free. I hope that helps someone, or me in the future, when I forget how it works.
I love Linux. Always have, always will. I run Linux (mostly RHEL and Fedora) on
a multitude of devices, from Raspberry Pi's to an old laptop functioning as a server,
and VMs on my NAS.
But I have also ended up (long story) doing a lot of work on MacOS with Apple silicon,
so I need a way to work on Ansible content from time to time, with a fast inner
development loop. Translated: I want a fast way to quickly test my Ansible "code" on
MacOS.
Roles and collections
I maintain a modest set of
collections. Mostly for fun, but also
to understand the workflow of my customers (I'm part of the Red Hat automation sales
team). I have one for Gitea and
act_runner, I have one for
atuin and I am working on one for starship.
As you might see, those current collections and any future ones I write, are aimed at
Linux machines, and RHEL in particular, either on x86_64 (amd64) or on aarch64 (arm64).
Writing roles and collections on MacOS
Writing a role or collection on MacOS is pretty easy. Whether you want to use VSCode,
vim or anything else, everything is available on MacOS (as it is on Linux).
The tricky thing is to test the roles you write on MacOS on local Linux infrastructure,
and in particular to test the roles on multiple architectures with a reasonable amount
of speed. Especially that last part is hard. I have tried various things involving VMs
and containers with qemu, and though that functionally works, it is sloooooow.
Rosetta
Then I read up on Rosetta. Rosetta is a binary
translator that makes it very fast and very convenient to run x86_64 software on an m1,
m2 or m3 aarch64 processor. It is FAST! It just wasn't very convenient to use when testing
roles on multiple architectures in VMs on MacOS.
Setting up the VM
What I wanted to have was an aarch64 Linux VM on MacOS, that allowed me to run x86_64
containers for molecule testing with Rosetta as a translation layer with as little
hassle as possible. (As said, I would have loved to use qemu for this, but it's just too
slow.)
Basically, what you do is create a Lima VM on MacOS (that's the quickest), pass some
flags during creation to have it mount the Rosetta translation binary, and configure the
VM to invoke Rosetta whenever you execute an x86_64 binary.
Lima makes it easy to use Rosetta in the Linux VM. It's a matter of passing the
--rosetta flag (as shown above) when creating a new machine. But in order to
automatically invoke Rosetta when we call an x86_64 binary, we need to do a couple of
things.
First of all, we need to drop a small config file 1 as
/usr/lib/binfmt.d/rosetta.conf. This file tells the operating system to call Rosetta
when it tries to open a file with a certain set of magic
bytes.
Then, we need to tweak the binfmt service itself a bit. When the binfmt service will
first start, it does so before the Rosetta share is mounted. Therefore, we tell it to
restart on failure after 5 seconds. Hardly a noticable delay and simple enough. This is
achieved by a systemd drop-in:
Because I run my tests on Fedora :heart, I needed to add some additional tasks to
configure the SELinux policy for Rosetta. Rosetta does not run out of the box on
a Fedora machine. That is because Rosetta needs to be mounted over NFS and it seems to
need to be run from that location. I haven't researched this, but copying over the
Rosetta binary to the VMs filesystem didn't seem to work at all.
Because the default SELinux policy disallows processes with init_t to execute files
with an nfs_t label, we have to teach SELinux that this is OK behaviour for now.
The type enforcement file you will need for this, is as follows:
Yes, that's right. At the moment, my Ansible dev workflow uses Docker CE. I'm planning
on making it work with Docker, but in all honesty, it's still slightly easier to use
Docker for molecule than it is to use podman. Especially when you plan to run molecule
tests both locally, and as part of tests on GitHub.
Virtualenv
I like to keep anything I install through pip in virtualenvs. Makes it easier to test
updates and makes it easier to work with different versions of Python packages for
different use cases. My venv tool of choice is virtualenvwrapper.
I just want to get that installed, and create a virtualenv with all my Ansible
dependencies in it, so I only have to log into my VM, run workon ansible and start
doing whatever it is I need to do.
Making this quick and easy
I wrapped all of the above tasks in an Ansible playbook for my (and your) convenience.
You can find it on GitHub. In order to
use it, you have to do six things:
Install lima through your package manager of choice. I use brew, so I go brew
install lima
Locally install Ansible on your Mac. I use a virtualenv for that, but since you are
here, reading this, I assume you'll know how to do this
Create a Fedora VM called "fedora" with limactl.
Clone the repo from GitHub and cd to it
Copy inventory.tmpl to inventory and update it with your username
Run the playbook using ansible-playbook setup.yml
After that, you can navigate to the Ansible content you are working on on your Mac, and
simply run limactl shell fedora to be dropped in the VM in the same directory. And
after running workon ansible, you'll have all the Ansbile tools you need to start
working on your collection or role.
As my readers may be aware, I have been a member of the Fedora Engineering Steering Committee (FESCo) for over a decade. One of the primary responsibilities of this nine-person body is to review the Fedora Change Proposals submitted by contributors and provide feedback as well as being the final authority as to whether those Changes will go forth. I take this responsibility very seriously, so when this week the Fedora KDE community brought forth a Change Proposal to replace GNOME Desktop with KDE Plasma Workspaces as the official desktop environment in the Fedora Workstation Edition, I decided that I would be remiss in my duties if I didn’t spend some serious time considering the decision.
As long-time readers of this blog may recall, I was a user of the KDE desktop environment for many years, right up until KDE 4.0 arrived. At that time, (partly because I had recently become employed by Red Hat), I opted to switch to GNOME 2. I’ve subsequently continued to stay with GNOME, even through some of its rougher years, partly through inertia and partly out of a self-imposed responsibility to always be running the Fedora/Red Hat premier offering so that I could help catch and fix issues before they got into users’ and customers’ hands. Among other things, this led to my (fairly well-received) series of blog posts on GNOME 3 Classic. As it has now been over ten years and twenty(!) Fedora releases, I felt like it was time to give KDE Plasma Workspaces another chance with the release of the highly-awaited version 6.0.
How will I do this?
I’ve committed to spending at least a week using KDE Plasma Workspaces 6 as my sole working environment. This afternoon, I downloaded the latest Fedora Kinoite installer image and wrote it to a USB drive.1 I pulled out a ThinkPad I had lying around and went ahead with the install process. I’ll describe my setup process a bit below, but (spoiler alert) it went smoothly and I am typing up this blog entry from within KDE Plasma.
What does my setup look like?
I’m working from a Red Hat-issued ThinkPad T490s, a four-core Intel “Whiskey Lake” x86_64 system with 32 GiB of RAM and embedded Intel UHD 620 graphics. Not a powerhouse by any means, but only about three or four years old. I’ve wiped the system completely and done a fresh install rather than install the KDE packages by hand onto my usual Fedora Workstation system. This is partly to ensure that I get a pristine environment for this experimen and partly so I don’t worry about breaking my existing system.
Thoughts on the install process
I have very little to say about the install process. It was functionally identical to installing Fedora Silverblue, with the minimalist Anaconda environment providing me some basic choices around storage (I just wiped the disk and told it to repartition it however it recommends) and networking (I picked a pithy hostname: kuriosity). That done, I hit the “install” button, rebooted and here we are.
First login
Upon logging in, I was met with the KDE Welcome Center (Hi Konqi!), which I opted to proceed through very thoroughly, hoping that it would provide me enough information to get moving ahead. I have a few nitpicks here:
First, the second page of the Welcome Center (the first with content beyond “this is KDE and Fedora”) was very sparse, saying basically “KDE is simple and usable out of the box!” and then using up MOST of its available screen real estate with a giant button directing users to the Settings app. I am not sure what the goal is here: it’s not super-obvious that it is a button, but if you click on it, you launch an app that is about as far from “welcoming” as you can get (more on that later). I think it might be better to just have a little video or image here that just points at the settings app on the taskbar rather than providing an immediate launcher. It both disrupts the “Welcome” workflow and can make less-technical users feel like they may be in over their heads.
I actually think the next page is a much better difficulty ramp; it presents some advanced topics that they might be interested in, but it doesn’t look quite as demanding of them and it doesn’t completely take the user out of the workflow.
Next up on the Welcome Center was something very welcome: an introduction to Discover (the “app store”). I very much like this (and other desktop environments could absolutely learn from it). It immediately provides the user with an opportunity to install some very popular add-ons.2
The next page was a bit of a mixed bag for me. I like that the user is given the option to opt-in to sharing anonymous user information, but I feel like the slider and the associated details it provided are probably a bit too much for most users to reasonably parse. I think this can probably be simplified to make it more approachable (or at least bury the extra details behind a button; I had to extend the window from its default size to get a screenshot).
At the end of the Welcome Center was a page that gave me pause: a request for donations to the KDE project. I’m not sure this is a great place for it, since the user hasn’t even spent any time with the environment at all yet. It seems a bit too forwards with asking for donations. I’m not sure where a better place is, but getting begged for spare change minutes after installing the OS doesn’t feel right. I think that if we were to make KDE the flagship desktop behind Fedora Workstation, this would absolutely have to come out. I think it gives a bad first impression. I think a far better place to leave things would be the preceding page:
OK, so let’s use it a bit!
With that out of the way, I proceeded to do a bit of setup for personal preferences. I installed my preferred shell (zsh) and some assorted CLI customizations for the shell, vi, git, etc. This was identical to the process I would have followed for Silverblue/GNOME, so I won’t go into any details here. I also have a preference for touchpad scrolling to move the page (like I’m swiping a touch-screen), so I set that as well. I was confused for a bit as it seemed that wasn’t having an effect, but I realized I had missed that “touchpad” was a separate settings page from “mouse” and had flipped the switch on the wrong devices. Whoops!
In the process of setting things up to my liking, I did notice one more potential hurdle for newcomers: the default keyboard shortcuts for working with desktop workspaces are different from GNOME, MacOS and Windows 11. No matter which major competitor you are coming from, this will cause muscle-memory stumbles. It’s not that any one approach is better than another, but the fact that they are all completely different makes me sigh and forces me to think about how I’m interacting with the system instead of what I want to do with it. Unfortunately, KDE did not make figuring this out easy on me; even when I used the excellent desktop search feature to find the keyboard shortcut settings, I was presented by a list of applications that did not clearly identify which one might contain the system-wide shortcuts. By virtue of past experience with KDE, I was able to surmise that the KWin application was the most likely place, but the settings app really didn’t seem to want to help me figure that out. Then, when I selected KWin, I was presented with dozens of pages of potential shortcuts, many of which were named similarly to the ones I wanted to identify. This was simply too many options with no clear way to sort them. I ended up resorting to trying random combinations of ctrl, alt, meta and shift with arrow keys until I eventually stumbled upon the correct set.
Next, I played around a bit with Discover, installing a pending firmware update for my laptop (which hadn’t been turned on in months). I also enabled Flathub and installed Visual Studio Code to see how well Flatpak integration works and also for an app that I know doesn’t natively use Wayland. That was how I discovered that my system had defaulted to a 125% fractional scaling setup. In Visual Studio Code, everything looked very slightly “off” compared to the rest of the system. Not in any way I could easily put my finger to, until I remembered how badly fractional scaling behaved on my GNOME system. I looked into the display settings and, sure enough, I wasn’t at an integer scaling value. Out of curiosity, I played around with the toggle for whether to have X11 apps scale themselves or for the system to do it and found that the default “Apply scaling themselves” was FAR better looking in Visual Studio Code. At the end of the day, however, I decided that I preferred the smaller text and larger available working area afforded me by setting the scaling back to 100%. That said, if my eyesight was poorer or I needed to sit further away from the screen, I can definitely see the advantages to the fractional scaling and I was very impressed by how sharp it managed to be. Full marks on that one!
I next went to play around in Visual Studio Code with one of my projects, but when I tried to git clone it, I hit an issue where it refused my SSH key. Digging in, I realized that KDE does not automatically check for keys in the default user location (~/.ssh) and prompt for their passphrases. I went ahead and used ssh-add to manually import them into the SSH keyring and moved along. I find myself going back and forth on this; on the one hand, there’s a definite security tradeoff inherent in allowing the desktop to prompt (and offer to save) the passphrase in the desktop keyring (encrypted by your login password). I decline to save mine persistently, preferring to enter it each time. However, there’s a usability tradeoff to not automatically at least launching an askpass prompt. In any case, it’s not really an issue for me to make this part of my usual toolbox entry process, but I’m a technical user. Newbies might be a bit confused if they’re coming from another environment.
I then went through the motions of getting myself signed in to the various messaging services that I use on a daily basis, including Fedora’s Matrix. Once signed in there via Firefox, I was prompted to enable notifications, which I did. I then discovered the first truly sublime moment I’ve had with Plasma Workspaces: the ephemeral notifications provided by the desktop. The way they present themselves, off to the side and with a vibrant preview window and show you a progress countdown until they vanish is just *chef’s kiss*. If I take nothing else away from this experience, it’s that it is possible for desktop notifications to be beautiful. Other desktops need to take note here.
I think this is where I’m going to leave things for today, so I’ll end with a short summary: As a desktop environment, it seems to do just about everything I need it to do. It’s customizable to the point of fault: it’s got so many knobs to twist that it desperately needs a map (or perhaps a beginner vs. expert view of the settings app). Also, the desktop notifications are like a glass of icy lemonade after two days lost in the desert.
This was actually my first hiccough: I have dozens of 4 GiB thumbdrives lying around, but the Kinoite installer was 4.2 GiB, so I had to go buy a new drive. I’m not going to ding KDE for my lack of preparedness, though! ︎
Unfortunately I hit a bug here; it turns out that all of those app buttons will just link to the updates page in Discover if there is an update waiting. I’m not sure if this is specific to Kinoite yet. I’ll be investigating and filing a ticket about it in the appropriate place. ︎
A few people (and multi-billion dollar companies!) have asked for my response to the xz backdoor. The fwupd metadata that millions of people download every day is a 9.5MB XML file — which thankfully is very compressible. This used to be compressed as gzip by the LVFS, making it a 1.6MB download for end-users, but in 2021 we switched to xz compression instead.
What actually happens behind the scenes is that the libxmlb library loads the optionally compressed metadata into a mmap-able binary blob, and then it gets used by fwupd to look for new updates for specific hardware. In libxmlb 0.3.3 we added support for xz as a compression format. Then fwupd 1.8.7 was released with xz support, preferring the xz format to the “legacy” gz format — as the metadata became a 1.1MB download, saving significant amounts of data from the CDN.
Then this week we learned that xz wasn’t the kind of thing we want to depend on. Out of an abundance of caution (and to be clear — my understanding is there is no fwupd or LVFS security problem of any kind) I’ve switched the LVFS to also generate zstd metadata, make libxmlb no longer hard depend on lzma and switched fwupd to prefer the zstd metadata over the xz metadata if the installed version of libjcat supports it. The zstd metadata is also ~3% smaller than xz (and faster to decompress), but the real benefit is that I now trust it a lot more than xz.
I’ll be doing new libxmlb and fwupd releases with the needed changes next week.
Version 4.2 of syslog-ng introduced a healthcheck option to syslog-ng-ctl. It prints three syslog-ng-related metrics on screen – if it can reach syslog-ng, that is. You can use it from scripts to monitor the health of syslog-ng.
Before you begin
The healthcheck option was added to syslog-ng-ctl in version 4.2. You need this or a later syslog-ng version to use this option. It is already available in the most recent Linux distributions. If you use an LTS Linux distribution, then check https://syslog-ng.org/3rd-party-binaries/ for 3rd party repositories for your OS.
If you want to send latency values printed by syslog-ng-ctl to Elasticsearch, you also need the jo utility: https://github.com/jpmens/jo This is available in several Linux distributions.
Testing from the command line
You can start syslog-ng-ctl from the command line or use it in your scripts. The -h option prints some help text on the terminal:
~# syslog-ng-ctl healthcheck --help
Usage:
syslog-ng-ctl [OPTION…] syslog-ng-ctl
Health check
Help Options:
-h, --help Show help options
Application Options:
-t, --timeout maximum seconds to wait for healthcheck results (default: 15)
-c, --control=<socket> syslog-ng control socket
This command line starts the health check with a five-second timeout. However, in my tests, the latency values stayed under one millisecond even during heavy load:
I tried to disable syslog-ng for a test, but I could not test the timeout feature this way, as syslog-ng-ctl detected that there is something wrong at the other end:
I wanted to see how the latency values printed by syslog-ng-ctl change over time. To check this, I created a cron job to run syslog-ng-ctl once a minute, and configured syslog-ng to send the results to Elasticsearch. The output of syslog-ng-ctl cannot be directly pushed to syslog-ng. However, using jo, you can turn the output of syslog-ng-ctl into JSON format. Syslog-ng can parse that and forward it to Elasticsearch.
~# cat health.sh
#!/bin/bash
/usr/sbin/syslog-ng-ctl healthcheck | sed 's/ /=/' | jo | nc 127.0.0.1 514
The sed rule turns the output of syslog-ng-ctl into the format expected by jo. The nc command forwards the results to syslog-ng, listening on port 514 on localhost.
You should append the following configuration snippet to syslog-ng.conf or – if your configuration supports it – store in a new .conf file under the /etc/syslog-ng/conf.d/ directory.
So, what does the above configuration do? The source is listening for a TCP connection and does not parse the incoming message. The reason is that the tcp() source uses an RFC3164 parser by default, but we collect JSON-formatted messages. The next step is that a JSON parser parses the message and turns it into name-value pairs. We have two destinations: a JSON-formatted text file, and Elasticsearch.
Here, we depend on type support, which was introduced in syslog-ng 4.0. The jo utility generates JSON from the syslog-ng-ctl output with proper type support. When version 3.X of syslog-ng parsed it, numbers were turned into strings. With version 4.0 and later, the type information is preserved. You can forward the parsed name-value pairs without any further preparation to Elasticsearch, and they will be stored with the correct type in the database.
Testing
Once you reloaded the syslog-ng configuration, you should test it. First, just start the script from the command line and check the Elasticsearch web interface for messages in the snghealth database. If everything works as expected, you should put the script in cron, so it runs regularly. Soon, you should be able to visualize the syslog-ng health data. In my case, latency stayed under one millisecond even under heavy load:
What is next?
In my test environment, I could not overload syslog-ng and increase latency. However, in a larger production environment, you might create alerts based on latency values, or if syslog-ng times out on health checks. If running Kubernetes, you could base liveness probes on this as well.
-
If you have questions or comments related to syslog-ng, do not hesitate to contact us. You can reach us by email or even chat with us. For a list of possibilities, check our GitHub page under the “Community” section at https://github.com/syslog-ng/syslog-ng. On Twitter, I am available as @PCzanik, on Mastodon as @Pczanik@fosstodon.org.
We’ve just had another magnificent event this past March in beautiful Pasadena for the 21st edition of the Southern California Linux Expo, the largest community-driven linux and open source conference in North America. Fedora and its crew are proud of have been participated since the conference’s 8th edition back in 2009!. It may sound like a no biggie, but as the conference grows older, bigger and more important, so does the commitment, responsability and even the logistics to provide a memorable experience to the visitors.
This is not the first time that I act as event owner, but this is the first time that I experienced with the most intensity the responsability of having everything ready and putting all together in order to meet the expectations of the reputation that preceeds us. I don’t think I’ve talked about it in any of my past reports, but there are a lots of things that need to be arranged before Day 1, this is why we start preparing everything in the Fall of the previous year. Just to mention some of the most relevant: to poll among Fedorians for interest/intention of attending the event and to work for our project during the event, to create the event page, to create the budget estimation, to create the budget approval and follow up, to request the swag to give away in the booth, request the shipping of the event box for booth setup, to contact the organizers to request for participation and follow up, to request the creation of the Fedora Badge for the event and to print the poster for scanning it, and a lot more!!. I don’t pretend to take full credit for all of these, but I’d like to use this opportunity to thank to the fantastic Fedora crew that made it possible. Thank you Perry Rivera for helping me with many of this tasks and for volunteering as co-owner of the event. Thank you Brian Monroe for assisting with the event box and swag shipping to your personal address and also for your remarkable booth duty. Thank you Scott Williams for the passion in the project and the way you keep people interested in it. And thank you Justin Flory for all your support
Thank you guys, you Rock!
So, here we are, Thursday afternoon, one day before the exhibition floor opens.
This day is used for co-located events like Kubernetes Community Day, DevOps LA, Nixcon, Ubucon, etc.I made sure that we have everything ready for the booth setup, not only the Fedora stuff but also the essentials: power strips, chairs, networking, trash can, etc. After this, I had the opportunity to attend a few talks and workshops of the ongoing events. I personally found KWAAIÂ and NixOS very interesting and worth of taking a more detailed look at them.
Our good friends Carl George and Shaun McCaunce from the CentOS Project offered a talk on CentOS and a workshop on packaging that resulted in great interest from the audience and helped to clear the air and to clarify the relationship between Fedora, CentOS and RHEL.
Later in the afternoon we had some time for networking in a cocktail offered by Kwaii, and we had a chance to talk and spend some time with our Fedora Project Leader Matthew Miller.
On Friday we were all set for the Exhibit Hall, just waiting for it to open so we could receive the visitors to our booth. Friday is typically a busy day and this year was no exception, we had a lot of visitor in our booth and many of them stayed for a while, commenting on their experience with Fedora or asking for specific question ot even tech doubts.
We closed the day with a mexican dinner with all of the crew and our friends from CentOS, a delightful evening that prepared us for the longest day of the conference: Saturday.
And along came Saturday. This day is busy because Exhibit Hall opens from 10:00 to 18:00 and it is when we have the largest number of visitors. There are three things that I’d like to highlight from this day that made somehow a difference with previous editions.
The first is that we were giving away raffle tickets to our booth’s visitors for some of the swag that we had, and this created a different environmet, new expectations, people gathered at the times of the raffles and -for many- it was a way to identify us and keep us under their radar.
Another highlight is that this day they scheduled the talks of our Fedora ambassadors and our Fedora Leaders discussion panel, unfortunatelly they were scheduled at the same time and it was hard to attend them live
RedHat’s Brian Proffitt took care of our booth so I could be able to get a few pictures of both. Thank you Brian !
And the third highlight is a bit personal, since I was alone in charge of the booth while my friends were at their talks, I had to receive a couple of guided tours that normally are students or newbies to Linux and pitch Fedora in less than a minute. The pressure to compress so many things I had to say about Fedora and to summarize them in so little time
Sunday is the most quiet day, Exhibit Hall closes at 14:00 and most exhibitors are wrapping up or ran out of swag, not our case We ran a few raffles and wrapped up as well.
I am very satisfied with the outcome of this edition. We have now a mean for continuos communication between the crew, we have started processing new ideas (like bringing new and fresh faces to promote Fedora) and started working on them, we’d like to share our experience with SCaLE during these fourteen editions that we have participated to a wider Fedora audience -thinking about Flock- and continue improving the Fedora presence and contributing for its acceptance. I’m excited for the future.
Josh and Kurt talk about the recent events around XZ. It’s only been a few days, and it’s amazing what we already know. We explain a lot of the basics we currently know with the attitude much of these details will change quickly over the coming week. We can’t fix this problem as it stands, we don’t know where to start yet. But that’s not a reason to lose hope. We can fix this if we want to, but it won’t be flashy, it’ll be hard work.
Josh and Kurt talk about the security.txt file. It’s not new, but it’s not something we’ve discussed before. It’s a great idea, an easy format, and well defined. It’s not high on many of our todo lists, but it’s something worth doing.
A while ago, I posted about using SSH to proxy traffic within a Nebula network context. In the last few months, I changed my implementation because SSH required some steps and accesses that I was not fully happy with.
In the previous iteration, I was using SSH as a SOCKS proxy. The problem, though, is that I need to set up the connection every time and use my SSH credentials, so it becomes difficult to have it always on.
This is part 6 of a multi-part series. See part 1 for the beginning of the series.
Wiping drives
To properly wipe a drive so it is effectively unrecoverable, the best solution is to use DBAN. It can be downloaded from https://sourceforge.net/projects/dban/.
This uses a bit of a shell scripting trick to avoid multiple commands and copy & paste, but it is still fairly simple. The output of blockdev --getsz gives us the size of the device in 512-byte blocks, so we divide that number by 2 to get the size in 1kB blocks, which we pass to the -m option (with a trailing k) to denote kB) to specify the maximum amount of data to transfer. Using a default block size of 1MB (-b) with a fallback of 4kB (-B, to match the host page size, which is required for direct I/O) should give us decent throughput.
Note that we're using -D to turn on direct I/O to the destination drive (/dev/sda), but we're not using direct I/O (-d) to read /dev/zero since /dev/zero is a character device that does not support direct I/O.
To just clear the MS-DOS partition table (and boot sector) on /dev/sda, you could do the following:
This is part 7 of a multi-part series. See part 1 for the beginning of the series.
Software RAID
It's becoming increasingly common (in 2009) on desktop PCs to use some form of BIOS-based software RAID. In most cases dealing with a single-drive failure in a software RAID isn't terribly difficult. For example, with NVIDIA's software RAID, even when one drive out of a stripe (RAID 0) set fails, if the drive is recoverable, you can simply clone it to a new identically-sized drive and the RAID will just work. Unfortunately, this isn't so simple with Intel's software RAID, which appears to store the serial numbers of the drives in the RAID metadata, meaning an exact clone won't work. While it would most likely be possible to simply edit the RAID metadata using hexedit to update the drive information, a somewhat simpler solution is to make a backup clone of the drives in the array, then re-create the RAID exactly as it was before in the RAID BIOS, then boot into Linux and run testdisk on the RAID device. More on that in part 8.
Most often the RAID metadata for drives in a software RAID volume is stored toward the end of the drive. In some cases, if you are forced to clone a failing RAID drive to a larger drive, you can make Linux (and maybe the BIOS and Windows) see the drive as a RAID device by copying the last few blocks from the failing drive to the last few blocks of the replacement drive.
Unfortunately, the ways that hardware RAID controllers store metadata don't tend to be quite as predictable as software RAID. If you attach a hardware RAID member drive to a non-RAID controller, some of the tricks mentioned above might work, but there are by no means any guarantees.
Also be aware that hardware RAID controllers are very likely to take a drive offline at the first sign of an error rather than report back the error and continue as most non-RAID controllers would. While this makes hardware RAID controllers largely unusable for data recovery, it does mean that a failing RAID member drive is quite likely to be recoverable.
Musescore is a wonderful tool. It has made a huge impact on my musical development over the past couple decades. Sheet music is the primary way I communicate and record musical ideas, and Musescore the tool and musecore.com have combined to make a process that works for me and my musical needs.
I have also spent a few years writing software, and the methods that we have learned to use in software development have evolved due to needs of scale and flexibility. I would like to apply some of those lessons to how I manage sheet music. But there are disconnects.
The biggest issue I have is that I want the same core song in multiple different but related formats. The second biggest issue is that I want to be able to make changes to a song, and to collaborate with other composers in making those changes.
The Sheet music I work with is based on the western notation system. I use a fairly small subset of the overall notation system, as what I am almost always working towards is a musical arrangement for small groups. The primary use case I have is for lead sheets: a melody line and a series of chords for a single instrument. Often, this is for a horn player. I need to be able to transpose the melody line into the appropriate key and range for that particular horn: E flat for a Baritone sax, C for a Flute, B flat for a saxophone, C but in Bass clef for a Trombone.
The second use case I have is to be able to arrange a section harmonically for a set of instruments. This means reusing the melody from a lead sheet, but then selecting notes for the other instruments to play as accompaniment. Often, this can be done on piano first, and then allocation the notes the piano plays out to the single-note horns.
I also wish to make play-along recordings, using ireal pro. This uses a very small subset of the lead sheet information: really just the chords and the repeats. A more complex version could be used to build MMA versions.
When I work with a more complex arrangement, I often find that I change my mind on some aspect: I wish to alter a repeat, a chord symbol, or the set of notes in the melody line.ideally that would be reflected through all the various aspects of the score.
The musescore files are stored in an xml format developed for the program. This XML file is compressed, and the the file extension reflects this: mscz. I have a song that is 40 measures long (32 with 8 bars repeated) and no more than 2 chords per measure, no more than 8 notes per measure. The underlying document used to store this song, when transposed for 6 different instruments is 22037 lines long. This is not a document format meant to be consumed by humans.
Here is a sample of how a single note is represented:
This is generated code. When software is responsible for creating more software, it will often product the output in a format that can then be consumed by another tool designed to read human readable source and convert it to binary. XML is a notoriously chatty format, and the number of lines in the Musescore file reflects that.
The “document” that we humans interface with is based on pen and paper. If I were to do this by hand, I would start with a blank page of pre-printed staff paper, and annotate on it such details as the clef, the key signature, the bar lines, the notes, and the chord symbols. This system is optimized for hand-written production, and human reading-on-the-stage consumption. This is how it is displayed on the screen as well. Why, then is the underlying file format so unfriendly?
Because file formats are based on text, and we have restricted that to very specific rules as well: Characters are represented as numeric values (ascii now unicode) and anything implying the layout on the page needs to be embedded in the document as well.
There are options for turn text into sheet music: ABC and Lilypond are both formats that do this. Why don’t I use those? I have tried in the past. But when I am writing music, I am thinking in terms of notation, not in terms of text, and they end up preventing me from doing what I need. They don’t solve the transposition or other problems as is. Perhaps the issue is that we need more tooling around one of these format, but then we return to the problem of generated code.
Once the sheet music is printed out, the options for annotating a revision is to write on the sheet music, or to edit the original source and reprinting it. In practice, both of these are done often. IN front of me on my desk is a copy of a tune where both chords and individual notes have been changed in pencil. After living with these revisions for quite some time, I eventually got them recorded back into the source file and reprinted it.
Carrying around reams of sheet music quickly becomes unfeasible. If you are in multiple groups, each of which have a large repertoire, the need to reduce the physical burden will likely lead you to an electronic solution: sheet music displayed on a tablet. However, the way that you distribute sheet music here will determine what options you have allowed for the artist to annotate corrections and instructions on the music in front of them: most PDFs don’t let you edit them, and you cannot write on a screen with a ball point pen.
As a band director, I would like to be able to note changes on a score for a particular group and automate the distribution of that change to the group.
As a band member I would like to be able to make changes to a score and have them show up when I view the score electronically. Ideally, these changes would be reflected in the ireal/MMA version that I use to practice as well as the sheet music I read.
As a collaborator, I would like to be able to submit a suggested change to a score as played by my group and have the music director be able to incorporate my suggestion into the score.
As a collaborator, I would like to be able to receive suggestions from another collaborator, and provide feedback on the suggestion if I decide not to include it as-is.
As an arranger, I would like to be able to come up with a score on piano and automate the process of converting it to a set of instruments.
As a band leader, I would like to be able to come up with a lead sheet in Musescore and automate the process of converting it to MMA and irealpro formats. I would like to be able to import the accompaniment from an irealpro or MMA format into a musescore document as a first pass for the percussion or other rhythm section arrangement.
I had long thought about an application to make it possible to work on music together with other people. At West Point we used to say Collaborate and Graduate. For this, I say:
In an enterprise distribution, such as RHEL, because of the very long life cycle (10 years or more), there is 2 opposite needs:
stability, which means keeping the same version for the whole life of the distribution (ex EL-7 still provides PHP 5.4)
new versions needed by new projects (ex: a lot of projects now require PHP 8)
So, this means we need to be able to distribute alternative versions in a safe way.
This of course also affects my repository, which has the goal to provide more alternative versions and extensions.
This is not a need for Fedora which has a very sort life cycle (6 months), so with no need for newer versions in a stable release.
1. The old time
Until EL-7, the main solution was to create 1 optional repository per version (ex: the RHWAS channel in EL-4).
This was not perfect, mostly working only for newer versions, raising conflicts because 2 versions were available in active repositories.
In EL-5 using different names was tried (e.g. php version 5.1 and php53 for version 5.3), this was a real nightmare, and this has been abandoned.
2. Software Collections
A nice idea appears in EL-6 and EL-7 to provide alternative versions in a separated RPM namespace, installed in a separated tree (/opt), allowing the installation of various versions simultaneously.
Mostly because of some design faults, the community rejected this and the project was abandoned in EL-8 (excepted for newer GCC, in devtoolset).
As initial design issues were fixed, I really appreciate SCL and still use them, and provides them in my repository, see My PHP development Workstation, mostly because I like being able to install various versions simultaneously.
3. Modularity
EL-8 introduced modularity, a new way to manage alternative versions in optional streams. When a stream is disabled its packages are ignored by dnf, when it is enabled its packages are preferred. This works very well for both newer and older versions.
3.1. Everything is module
In EL-8 the idea was to provide everything as modules. This was probably a terrible mistake that caused the community to reject it again.
Indeed, especially for libraries this probably doesn't make sense. This also creates a complex dependency tree, and a very complex build system (MBS).
3.2. Module only for alternatives
In EL-9 everything was greatly simplified. The base system works without modules that are only used for alternative versions (ex: PHP 8.0 by default, but 8.1 and 8.2 are available as modules).
This is probably how modularity should have been used from the beginning. And this works really smoothly. Also, MBS is not really required in this simple scheme, with a simple build configuration being enough.
But it was too late, and the community (mostly the Fedora one) had already killed it.
4. DNF version 5
This is the successor of DNF version 4 which introduces modules. But, as Fedora chose to stop using modules, the needed features are not implemented.
For now, dnf5 only supports enabling/disabling streams, but this is far from usable, and perhaps everything related to modularity will be dropped in the final version.
4.1. Fedora 40
In the upcoming Fedora 40, dnf is still version 4 by default, and dnf5 is also available for test.
Module management still works, despite a small regression which has a workaround.
4.2. Fedora 41
In the future Fedora 41, dnf version 5 should become the default, probably without modularity.
5. My repository
I plan to continue to provide modules for Fedora 40 and probably EL-10, with dnf 4.
I need to think about later versions, having to switch back to the old way (1 repo per version) makes me terribly sad and gives me nightmares.
I've read a proposal to switch back to provide alternative versions under a different namespace. Which seems like switching 10 years back, with a broken solution.
6. Conclusion
Of course, I dream of seeing Modularity support maintained in dnf 5 ;)
I'm disappointed with the bad Fedora community feedback on solutions proposed to solve Enterprise-only needs.
And what a waste of developer energy on these features (SCL and Modularity)
Release Candidate versions are available in the testing repository for Fedora and Enterprise Linux (RHEL / CentOS / Alma / Rocky and other clones) to allow more people to test them. They are available as Software Collections, for a parallel installation, the perfect solution for such tests, and also as base packages.
RPMs of PHP version 8.3.5RC1 are available
as base packages
in the remi-modular-test for Fedora 38-40 and Enterprise Linux≥ 8
in the remi-php83-test repository for Enterprise Linux 7
as SCL in remi-test repository
RPMs of PHP version 8.2.18RC1 are available
as base packages
in the remi-modular-test for Fedora 38-40 and Enterprise Linux≥ 8
in the remi-php82-test repository for Enterprise Linux 7
as SCL in remi-test repository
The Fedora 39, 40, EL-8 and EL-9 packages (modules and SCL) are available for x86_64 and aarch64.
PHP version 8.1 is now in security mode only, so no more RC will be released.
For many years, VPN companies have advertised their VPNs as a necessary tool for all people who want to preserve their privacy. For the same amount of time, I tried to explain to the people that this view made no sense if not for those company’s sales.
As an example, Onavo, a Meta subsidiary, used to advertise its services, highlighting that, among other advantages, using their product “protects your personal info”.
So Fedora Workstation 40 Beta has just come out so I thought I share a bit about some of the things we are working on for Fedora Workstation currently and also major changes coming in from the community.
Flatpak
Flatpaks has been a key part of our strategy for desktop applications for a while now and we are working on a multitude of things to make Flatpaks an even stronger technology going forward.
Christian Hergert is working on figuring out how applications that require system daemons will work with Flatpaks, using his own Sysprof project as the proof of concept application. The general idea here is to rely on the work that has happened in SystemD around sysext/confext/portablectl trying to figure out who we can get a system service installed from a Flatpak and the necessary bits wired up properly.
The other part of this work, figuring out how to give applications permissions that today is handled with udev rules, that is being worked on by Hubert Figuière based on earlier work by Georges Stavracas on behalf of the GNOME Foundation thanks to the sponsorship from the Sovereign Tech Fund. So hopefully we will get both of these two important issues resolved soon.
Kalev Lember is working on polishing up the Flatpak support in Foreman (and Satellite) to ensure there are good tools for managing Flatpaks when you have a fleet of systems you manage, building on the work of Stephan Bergman.
Finally Jan Horak and Jan Grulich is working hard on polishing up the experience of using Firefox from a fully sandboxed Flatpak. This work is mainly about working with the upstream community to get some needed portals over the finish line and polish up some UI issues in Firefox, like this one.
Toolbx
Toolbx, our project for handling developer containers, is picking up pace with Debarshi Ray currently working on getting full NVIDIA binary driver support for the containers. One of our main goals for Toolbx atm is making it a great tool for AI development and thus getting the NVIDIA & CUDA support squared of is critical.
Debarshi has also spent quite a lot of time cleaning up the Toolbx website, providing easier access to and updating the documentation there.
We are also moving to use the new Ptyxis (formerly Prompt) terminal application created by Christian Hergert, in Fedora Workstation 40. This both gives us a great GTK4 terminal, but we also believe we will be able to further integrate Toolbx and Ptyxis going forward, creating an even better user experience.
Nova
So as you probably know, we have been the core maintainers of the Nouveau project for years, keeping this open source upstream NVIDIA GPU driver alive. We plan on keep doing that, but the opportunities offered by the availability of the new GSP firmware for NVIDIA hardware means we should now be able to offer a full featured and performant driver. But co-hosting both the old and the new way of doing things in the same upstream kernel driver has turned out to be counter productive, so we are now looking to split the driver in two. For older pre-GSP NVIDIA hardware we will keep the old Nouveau driver around as is. For GSP based hardware we are launching a new driver called Nova.
It is important to note here that Nova is thus not a competitor to Nouveau, but a continuation of it.
The idea is that the new driver will be primarily written in Rust, based on work already done in the community, we are also evaluating if some of the existing Nouveau code should be copied into the new driver since we already spent quite a bit of time trying to integrate GSP there. Worst case scenario, if we can’t reuse code, we use the lessons learned from Nouveau with GSP to implement the support in Nova more quickly.
Contributing to this effort from our team at Red Hat is Danilo Krummrich, Dave Airlie, Lyude Paul, Abdiel Janulgue and Phillip Stanner.
Explicit Sync and VRR
Another exciting development that has been a priority for us is explicit sync, which is critical for especially the NVidia driver, but which might also provide performance improvements for other GPU architectures going forward.
So a big thank you to Michel Dänzer , Olivier Fourdan, Carlos Garnacho; and Nvidia folks, Simon Ser and the rest of community for working on this. This work has just finshed upstream so we will look at backporting it into Fedora Workstaton 40.
Another major Fedora Workstation 40 feature is experimental support for Variable Refresh Rate or VRR in GNOME Shell. The feature was mostly developed by community member Dor Askayo, but Jonas Ådahl, Michel Dänzer, Carlos Garnacho and Sebastian Wick have all contributed with code reviews and fixes. In Fedora Workstation 40 you need to enable it using the command
gsettings set org.gnome.mutter experimental-features "['variable-refresh-rate']"
PipeWire
Already covered PipeWire in my post a week ago, but to quickly summarize here too. Using PipeWire for video handling is now finally getting to the stage where it is actually happening, both Firefox and OBS Studio now comes with PipeWire support and hopefully we can also get Chromium and Chrome to start taking a serious look at merging the patches for this soon. Whats more Wim spent time fixing Firewire FFADO bugs, so hopefully for our pro-audio community users this makes their Firewire equipment fully usable and performant with PipeWire. Wim did point out when I spoke to him though that the FFADO drivers had obviously never had any other consumer than JACK, so when he tried to allow for more functionality the drivers quickly broke down, so Wim has limited the featureset of the PipeWire FFADO module to be an exact match of how these drivers where being used by JACK. If the upstream kernel maintainer is able to fix the issues found by Wim then we could look at providing a more full feature set. In Fedora Workstation 40 the de-duplication support for v4l vs libcamera devices should work as soon as we update Wireplumber to the new 0.5 release.
Another major feature landing in Fedora Workstation 40 that Jonas Ådahl and Ray Strode has spent a lot of effort on is finalizing the remote desktop support for GNOME on Wayland. So there has been support for remote connections for already logged in sessions already, but with these updates you can do the login remotely too and thus the session do not need to be started already on the remote machine. This work will also enable 3rd party solutions to do remote logins on Wayland systems, so while I am not at liberty to mention names, be on the lookout for more 3rd party Wayland remoting software becoming available this year.
This work is also important to help Anaconda with its Wayland transition as remote graphical install is an important feature there. So what you should see there is Anaconda using GNOME Kiosk mode and the GNOME remote support to handle this going forward and thus enabling Wayland native Anaconda.
HDR
Another feature we been working on for a long time is HDR, or High Dynamic Range. We wanted to do it properly and also needed to work with a wide range of partners in the industry to make this happen. So over the last year we been contributing to improve various standards around color handling and acceleration to prepare the ground, work on and contribute to key libraries needed to for instance gather the needed information from GPUs and screens. Things are coming together now and Jonas Ådahl and Sebastian Wick are now going to focus on getting Mutter HDR capable, once that work is done we are by no means finished, but it should put us close to at least be able to start running some simple usecases (like some fullscreen applications) while we work out the finer points to get great support for running SDR and HDR applications side by side for instance.
PyTorch
We want to make Fedora Workstation a great place to do AI development and testing. First step in that effort is packaging up PyTorch and making sure it can have working hardware acceleration out of the box. Tom Rix has been leading that effort on our end and you will see the first fruits of that labor in Fedora Workstation 40 where PyTorch should work with GPU acceleration on AMD hardware (ROCm) out of the box. We hope and expect to be able to provide the same for NVIDIA and Intel graphics eventually too, but this is definitely a step by step effort.
Let me start by introducing you to a great event that has been organized for over 30 years—yes, 30! The organizers are proud that this is Europe’s oldest conference on Gnu/Linux and free software.
It’s held in Zagreb, Croatia, and offers many ways to learn new stuff – Sessions, workshops, small mini-events on a particular topic, and many ways to network and meet people.
Why don’t you combine your thirst for knowledge with a trip to Zagreb where, apart from the food, drinks, and history, you will understand why there are chandeliers from a Las Vegas Casino in a Cathedral?
When I started living in the Czech Republic, the people from Prague tried to convince me that the city of Brno was a hoax and that it didn’t exist. I am still not convinced, and I plan to go and visit the DevConf this year to change my mind :)
Apart from the obvious joke, the DevConf in Brno has been held almost every year since 2009. The topics might vary throughout the years, but the hero is always the open source. The primary sponsor is Redhat, and you might see more focus on technologies and principles related to the software company, but this is usually okay.
This year’s conference will last three days and include ten different themes, including the good ol’ AI.
Attendance is free of charge, and no registration is required. Visit Brno, ensure it’s real, meet many new people, and learn something new.
— P.S. I am not associated with any of the events; I just want to support their enormous effort
This year, I am mentoring again with the Outreachy internship program. It is my third time mentoring for Outreachy and my second time with the Fedora Project. However, it is my first time mentoring as a Red Hat associate. What also makes this time different from before is that I am mentoring a non-engineering project with Outreachy. Or in other words, my project does not require an applicant to write any code. Evidently, the internship description was a hook. We received an extremely large wave of applicants literally overnight. Between 40-50 new contributors arrived to the Fedora Marketing Team in the first week. Planning tasks and contributions for beginners already took effort. Scaling that planning work overnight for up to 50 people simultaneously is extraordinarily difficult.
During this round, my co-mentor Joseph Gayoso and I experimented with new approaches at handling the tsunami wave. There are two competing forces at play. One, you need to provide engagement to top performers so they remain motivated to continue. Two, you need to provide new opportunities for emerging contributors to distinguish themselves. It is easier to do one of these but hard to do both simultaneously. However, Joseph and I agreed on something important. We agreed that all applicants should end the contribution phase with something practically useful. As mentors, we asked ourselves how to prepare applicants to be successful open source contributors beyond this one month.
In this article, you will get some practical takeaways for mentoring with Outreachy. First, I will share our practical approach for structuring and planning an open source project during the Outreachy contribution phase. Second, I will detail the guiding philosophy Joseph and I follow for how we planned the contribution phase.
About Outreachy
This article assumes you already know a thing or two about the Outreachy internship program. If not, Outreachy provides internships in open source and open science. Outreachy provides internships to people subject to systemic bias and impacted by underrepresentation in the technical industry where they live. You can read more on the Outreachy website.
What makes Outreachy unique is that the internships are remote and often open without geographic or nationality constraints. Applicants from nearly every continent of the world have participated in Outreachy. Also, Outreachy is distinguished by the contribution phase. For a one-month period, approved Outreachy applicants are encouraged to participate in the project community as a contributor. Applicants spend the month learning about the project, the community, the mentors, and the work involved for the internship. This provides applicants an opportunity to grow their open source identity. It also gives mentors an opportunity to assess applicants on their skills and communication abilities.
However, this contribution phase can be intimidating as a mentor, especially if you are new to mentoring with Outreachy. A wave of people eager to contribute could suddenly appear overnight at your project’s door steps. If you are not prepared, you will have to adapt quickly!
Pre-Requisite Tasks: Raising the Outreachy bar
My co-mentor and I knew that a wave of applicants was coming. However, we didn’t expect the wave to be as big as it was. After the first week of the contribution phase, we knew we needed a better way to scale ourselves. We were limited in our person-power. The approach we took to addressing the mental overload was defining pre-requisite tasks.
We defined pre-requisite tasks as tasks that any applicant MUST complete in order to be considered eligible for our internship. Without completing these tasks, we explained that final applications would not be accepted by mentors. The defining characteristics of these pre-requisite tasks were that they were personalized, repeatable, and measurable. We came up with five pre-requisite tasks that all applicants were required to complete beyond the initial qualification for Outreachy:
Each of these tasks were personalized to each applicant. They each have a unique account profile, with their pictures, time zones, and chat system usernames. The personal blog is a personal space on the Internet for each applicant to start writing new posts. The blog post prompts encouraged applicants to start filling up their blogs with Fedora content. The social media post helped applicants promote themselves as budding open source enthusiasts in their existing web spaces.
This approach had two benefits. First, it provided clear guidance to all newcomers and early-stage applicants on how to get started with contributing to Fedora for the Outreachy internship. This took a burden off of mentors answering the same questions about getting started. It also gave new applicants something to start on right away. Joseph and I were able to put more time into reviewing incoming contributions and brainstorming new tasks.
Portfolio-driven submissions for Outreachy
Toward the third week, many applicants had completed the pre-requisite tasks and were ready for more advanced tasks. Many had already taken on advanced projects already, beyond the pre-requisite tasks. Although the pre-requisite tasks did reduce the applicant pool, there were still between 20-30 people who completed them all. Again, the approach had to adapt as our ability to keep up with new contributions slowed down.
From here, we encouraged applicants to build personal portfolio pages that described their contributions with Fedora. This encouraged applicants to use the blog they built in the previous tasks, although they are not required to use their blog to host their portfolio. The only requirement we added was that it should be publicly visible on the Internet without a paywall. So, no Google Docs. Most applicants have ended up using their blog for this purpose though.
How did a portfolio help?
Building a portfolio solved multiple challenges for our Outreachy project at once. First, the portfolios will simplify how the project mentors review final applications after the deadline on April 2nd, 2024. It will be streamlined because we will have a single place we can refer to that describes the applicant’s achievements. It gives us a quick, easily shareable place to review and share with other stakeholders.
Second, it ends up being something useful to the applicant as well. The portfolio page captures a month’s worth of contributions to open source. For many applicants, this is their first time ever interacting with an open source community online. So, it is a big deal to block out a month of time to volunteer on a project in a competitive environment for a paid, remote internship opportunity. Writing a portfolio page gives applicants the confidence to represent their contributions to Fedora, regardless of whether they are selected for the Fedora internship. It becomes a milestone marker for themselves and for their professional careers.
Our philosophy: You win, we win.
This idea of applicants building something that is useful for themselves underpins the approach that Joseph and I took on structuring our non-engineering Outreachy internship. If I had to summarize the philosophy in one sentence, it might be like this:
Everyone who participants as an Outreachy applicant to Fedora should finish the contribution phase with more than they had at the start of the contribution phase.
myself
Our philosophy can be applied to engineering and non-engineering internships. However, applying the philosophy to our non-engineering project required improvisation as we went. There are examples of design-centered Outreachy internships, but I have not seen a marketing or community manager internship before. This was a challenge because there were not great models to follow. But it also left us room to innovate and try ideas that we have never tried before.
Adopting this philosophy served as helpful guidance on planning what we directed applicants to do during the contribution phase. It allowed us to think through ways that applicants could make real, recognizable contributions to Fedora. It also enables applicants to achieve a few important outcomes:
Get real experience in a real project.
Build their own brand as open source contributors.
Gain confidence at collaborating in a community.
The contribution phase is not yet over. So, we will continue to follow this philosophy and see where it guides us into the end of this phase!
Share your Outreachy mentoring experience!
Have you experienced or seen a marketing or community manager internship in Outreachy before? Know a project or a person who has done this? Or is this totally new to you? Drop a comment below with your thoughts. Don’t forget to share with someone else if you found this advice useful.
One Identity Cloud PAM Essentials is the latest security product by One Identity. It provides asset management as well as secure and monitored remote access for One Identity Cloud users to hosts on their local network. I had a chance to test PAM Essentials while still in development. While there, I also integrated it with syslog-ng.
From my previous blog, you could learn what PAM Essentials is, and how you can collect its logs using syslog-ng. This blog will show you how to work with the collected log messages and create alerts when somebody connects to a host on your local network using PAM Essentials.
On the syslog-ng side you need the syslog-ng Windows Agent (which is a commercial product) to collect the logs of the One Identity Network Agent. On the server side you can use both syslog-ng Premium Edition or Open Source Edition. The configuration I show works with both. In this case I used PE 7.0.34 (the currently available latest version), and the same configuration should work with any recent 3.X OSE version. You might need some minor changes for syslog-ng 4.X due to type support.
What we try to achieve
Before going into the syslog-ng configuration details, let me summarize again, what we try to achieve with using syslog-ng:
Collecting all logs related to PAM Essentials generated on the local network to a single location. This includes One Identity Network Agent logs, the Windows Eventlog of the host, where the software runs, and also the hosts where outside users connect through PAM Essentials.
Parsing Windows XML logs, so it is turned into easy-to-use name-value pairs.
Parsing One Identity Network Agent logs to find connection information.
Storing all incoming log messages into an Elasticsearch database, where logs can easily be searched.
Sending alerts to Slack instant messaging, once a connection is established through PAM Essentials.
And a few words about what we do not try to achieve. We collect Windows Eventlog from the host running the One Identity Network Agent, and all logs from the Linux hosts running the ssh servers. We even parse the XML-formatted logs to turn them into name-value pairs. However, we do not work with those logs any further (at least, not in this blog), just store them into local text files and into Elasticsearch. They are still useful: check what I wrote about central logging in my previous blog.
Forwarding logs from your ssh (Linux) host
We want to collect all PAM Essentials related log messages to a central location. It means that we also have to install syslog-ng on the Linux host(s) running the ssh server, where the outside user connects using PAM Essentials. The following configuration snippet works both with syslog-ng OSE and PE:
Note that the source name for local logs might be different on your system. Of course, the IP address of the syslog-ng server on your network is different, and on a production system you might want to filter what to forward, use disk-buffer, encryption, and so on. For testing, the above configuration is good enough.
Forwarding One Identity Network Agent and Windows eventlog
In my previous blog (URL TBD) I showed you how to configure the syslog-ng Windows Agent to forward Windows and One Identity Network Agent logs. Check that blog for information how to configure the syslog-ng Windows Agent.
Configuring the syslog-ng server for log collection and initial message parsing
The following configuration collects log messages both from Linux and Windows. It parses the Windows eventlog messages using an XML parser. In the end is saves all logs locally, and also to Elasticsearch.
# source for Linux clients, RFC3164source s_lin {tcp(port(514));};
# source for Windows clients, RFC5424
source s_win {
syslog(port(601));
};
# xml parser for Windows XML logs
parser p_xml {
xml(prefix('winxml.'));
};
# destination for Linux logsdestination d_fromlin {file("/var/log/fromlin");file("/var/log/fromlin.json" template("$(format-json --scope rfc5424 --scope dot-nv-pairs--rekey .* --shift 1 --scope nv-pairs)\n") );};# Elasticsearch destinationdestination d_elasticsearch {elasticsearch-http(index("syslog-ng")type("")user("elastic")password("Do2oFMbINS3hzfmR8uIV")url("https://172.16.167.182:9200/_bulk")template("$(format-json --scope rfc5424 --scope dot-nv-pairs--rekey .* --shift 1 --scope nv-pairs--exclude DATE @timestamp=${ISODATE})")tls(peer-verify(no)));};
# destination for Windows logs
destination d_fromwin {
file("/var/log/fromwin");
file("/var/log/fromwin.json" template("$(format-json --scope rfc5424 --scope dot-nv-pairs
--rekey .* --shift 1 --scope nv-pairs)\n") );
};
# log path for Linux logslog {source(s_lin);destination(d_fromlin);destination(d_elasticsearch);};
# log path for Windows logs
log {
source(s_win);
# syslog-ng-agent logs do not come in XML format
# only parse the rest
if ("${PROGRAM}" ne "syslog-ng-agent") {
parser(p_xml);
};
destination(d_fromwin);
destination(d_elasticsearch);
};
The Windows-related part should be mostly familiar from my previous blog. The only change there is the addition of an Elasticsearch destination. Why is that important? It makes viewing and searching name-value pairs parsed from Windows Eventlog a lot more easy. Yes, JSON-formatted text files are essential when you build a syslog-ng configuration, but a GUI is a lot more convenient for production use.
So, what is new here compared to my previous blog? Other than the previously mentioned Elasticsearch destination, the collection of Linux logs. There is a tcp() source, and a file destination, which writes both a traditional looking syslog file and JSON formatted messages. In this case JSON formatting does not make much sense, I am just too much used to creating it while working on configurations.
Both log path utilizes the same elasticsearch-http() destination, as it provides a single, easy to use web interface to search all the logs we collect.
Parsing connection logs
Now that we have all logs related to PAM Essentials generated on the local network collected to a single location, we can add one more thing to our configuration: alerting to slack when someone connects to a host on our local network using PAM Essentials.
First, let us take a look at the relevant log messages from the One Identity Network Agent log file, log.txt. The first one is generated when the user is connected, the second one when the connection is closed.
Actually, the above two lines are the content of MESSAGE macro in the message that the syslog-ng Windows Agent forwards. The original message is slightly shorter: the file name is added to the message by the syslog-ng Windows Agent. The content of this macro is what we have to parse using PatternDB.
PatternDB is a parser in syslog-ng, which can parse unstructured log messages and turn relevant information into name-value pairs. These name-value pairs can be used for filtering, or stored as name-value pairs for easier search. Of course syslog-ng does not know anything about the content of log messages by itself. PatternDB needs an XML database that describes the log messagges, and using that database syslog-ng can turn relevant information from the log messages into name-value pairs.
You can find the XML file describing the One Identity Network Agent connection logs below. Save it as oina.pdb (you can use any other name and extension, but this is the file name the syslog-ng.conf in this blog expects).
I do not want to go in depth how the PatternDB XML works, here I just share some of the most important information with you. Each rule in the database has pattern that describes the log message: the constant parts, the variable parts, how to find them in the log message and what to name the found information. This is followed by a test message and test values for the extracted values.
For us the most important information is the list of name-value pairs extracted from the log messages. In this case:
oi.filename: the name of the log file
oi.date: the date as written by the One Identity Network Agent
oi.level: the log level set by the One Identity Network Agent
oi.clientid: the unique identifier of the One Identity Network Agent
oi.sessionid: the unique identifier for the session (network connection) through PAM Essentials
oi.targethost: the host on the internal network, where the outside user connects through PAM Essentials
In this blog we use the oi.targethost name-value pair. If this exists in a log message, it means that a new connection is established. In this case we save the event in a separate file, and also send an alert to Slack.
So, what do we need to add to the previous configuration?
The PatternDB parser with the above XML file.
# patterndb parser for OI Network Agent connection logs
parser p_connect {
db-parser(file("/opt/syslog-ng/etc/oina.pdb"));
};
# Slack destination
destination d_slack {
slack(
hook-url("https://hooks.slack.com/services/T06xxxDFE/B06xxxJLA/gywxxxUdpmJOC")
template("OI Network Agent connection at ${DATE} to ${oi.targethost}")
);
};
Add the parser and the destination to the log path for Windows logs.
# log path for Windows logs
log {
source(s_win);
# syslog-ng-agent logs do not come in XML format
# only parse the rest
if ("${PROGRAM}" ne "syslog-ng-agent") {
parser(p_xml);
};
parser(p_connect);# send alert if there is a connection through the OI Network Agent# this macro is only created from connection logsif ("${oi.targethost}" ne "") {destination {file("/var/log/alert" template("${DATE} OI Network Agent connection to ${oi.targethost}\n"));};destination(d_slack);};
destination(d_fromwin);
destination(d_elasticsearch);
};
The final configurations
For your copy & paste convenience I put together everything below. You should append it to syslog-ng.conf, or if your syslog-ng.conf supports it, create a new configuration snippet for it under the /etc/syslog-ng/conf.d/ directory.
######
# PAM Essentials
# source for Linux clients, RFC3164
source s_lin {
tcp(port(514));
};
# source for Windows clients, RFC5424
source s_win {
syslog(port(601));
};
# xml parser for Windows XML logs
parser p_xml {
xml(prefix('winxml.'));
};
# patterndb parser for OI Network Agent connection logs
parser p_connect {
db-parser(file("/opt/syslog-ng/etc/oina.pdb"));
};
# destination for Linux logs
destination d_fromlin {
file("/var/log/fromlin");
file("/var/log/fromlin.json" template("$(format-json --scope rfc5424 --scope dot-nv-pairs
--rekey .* --shift 1 --scope nv-pairs)\n") );
};
# Elasticsearch destination
destination d_elasticsearch {
elasticsearch-http(
index("syslog-ng")
type("")
user("elastic")
password("Do2oFMbINS3hzfmR8uIV")
url("https://172.16.167.182:9200/_bulk")
template("$(format-json --scope rfc5424 --scope dot-nv-pairs
--rekey .* --shift 1 --scope nv-pairs
--exclude DATE @timestamp=${ISODATE})")
tls(peer-verify(no))
);
};
# destination for Windows logs
destination d_fromwin {
file("/var/log/fromwin");
file("/var/log/fromwin.json" template("$(format-json --scope rfc5424 --scope dot-nv-pairs
--rekey .* --shift 1 --scope nv-pairs)\n") );
};
# Slack destination
destination d_slack {
slack(
hook-url("https://hooks.slack.com/services/T06PxxxFE/B06xxxA/gywQkG8XXXmJOC")
template("OI Network Agent connection at ${DATE} to ${oi.targethost}")
);
};
# log path for Linux logs
log {
source(s_lin);
destination(d_fromlin);
destination(d_elasticsearch);
};
# log path for Windows logs
log {
source(s_win);
# syslog-ng-agent logs do not come in XML format
# only parse the rest
if ("${PROGRAM}" ne "syslog-ng-agent") {
parser(p_xml);
};
parser(p_connect);
# send alert if there is a connection through the OI Network Agent
# this macro is only created from connection logs
if ("${oi.targethost}" ne "") {
destination {file("/var/log/alert" template("${DATE} OI Network Agent connection to ${oi.targethost}\n"));};
destination(d_slack);
};
destination(d_fromwin);
destination(d_elasticsearch);
};
Testing
Once you saved and reloaded the syslog-ng configuration, you are ready for some testing. Luckily testing is now easy. All you have to do is to connect to a machine on your local network through PAM Essentials and check your logs. The above configuration saves alerts to a text file too, so you can check alerting even without configuring Slack or any other instant messaging service for syslog-ng previously.
You should see similar messages in /var/log/alert:
Mar 12 16:37:08 OI Network Agent connection to 127.80.65.77
Mar 12 16:37:19 OI Network Agent connection to 127.80.65.77
Mar 12 16:38:10 OI Network Agent connection to 172.16.167.182
You can find a screenshot from Slack below:
You can see that there is a target IP address from the internal network. However, there are some random looking IP addresses from the localhost: 127.80.65.77 It is used for management, and accessible only from localhost. Fun fact: the numbers are not random.
127 – local host
80 – ASCII ‘P’
65 – ASCII ‘A’
77 – ASCII ‘M
You can either live with the extra alerts, or modify the syslog-ng configuration to filter those out.
What is next?
Being able to search all PAM Essentials related log messages in a single place and receiving a real-time alert on instant messaging when a user logs in through PAM Essentials are both valuable additions to your PAM Essentials installation. You can further improve your configuration with a bit of correlation. This way you could also receive an alert when a session is closed without needing to check the PAM Essentials dashboard regularly for new session recordings to appear. You can gain some inspiration on implementation from one of my recent blogs: https://www.syslog-ng.com/community/b/blog/posts/aggregating-messages-in-syslog-ng-using-grouping-by Where I aggregated ssh login / logout messages.
-
If you have questions or comments related to syslog-ng, do not hesitate to contact us. You can reach us by email or even chat with us. For a list of possibilities, check our GitHub page under the “Community” section at https://github.com/syslog-ng/syslog-ng. On Twitter, I am available as @PCzanik, on Mastodon as @Pczanik@fosstodon.org.
Here are the release notes from Cockpit 314 and cockpit-ostree 201:
Diagnostic reports: Fix command injection vulnerability with crafted report names
Cockpit 270
introduced a possible local privilege escalation vulnerability with
deleting diagnostic reports (sosreport). Files in /var/tmp/ are
controllable by any user. In particular, an unprivileged user could
create an sosreport* file containing a ' and a shell command, which
would then run with root privileges when the admin Cockpit user tried
to delete the report.
This Cockpit version fixes the problem by removing the files with
direct system calls instead of a shell command.
This is tracked as CVE-2024-2947.
If you need to backport this to older cockpit versions, you can apply
the upstream patch.
If you cannot update or patch, then check the displayed report file
names for non-standard characters, in particular ', $, ( and `,
and don’t use Cockpit’s Diagnostic reports page to delete them.
Storage: Improvements to read-only encrypted filesystems
Cockpit now unlocks encrypted filesystems with a “read-only”
encryption layer when the filesystem itself is mounted read-only.
Ostree: Show OCI container origin
cockpit-ostree now detects and shows the origin, repository, and
branch name of native container repositories
in both the “OSTree source” card and the deployment list:
Try it out
Cockpit 314 and cockpit-ostree 201 are available now:
En ce mardi 26 mars, la communauté du Projet Fedora sera ravie d'apprendre la disponibilité de la version Beta de Fedora Linux 40.
Malgré les risques concernant la stabilité d’une version Beta, il est important de la tester ! En rapportant les bogues maintenant, vous découvrirez les nouveautés avant tout le monde, tout en améliorant la qualité de Fedora Linux 40 et réduisant du même coup le risque de retard. Les versions en développement manquent de testeurs et de retours pour mener à bien leurs buts.
La version finale est pour le moment fixée pour le 16 ou 23 avril.
Expérience utilisateur
Passage à GNOME 46 ;
L'environnement de bureau KDE Plasma change de version majeure avec sa nouvelle version 6 ;
Le fichier firefox.desktop est renommé en org.mozilla.firefox.desktop pour permettre son utilisation dans la barre de recherche de GNOME.
Gestion du matériel
Fourniture de ROCm 6 pour améliorer la prise en charge de l'IA et le calcul haute performance pour les cartes graphiques AMD ;
Passage à l'étape 2 de la prise en charge du noyau unifié nommée UKI (donc unifiant noyau, initrd, ligne de commande du noyau et signature) pour les plateformes avec UEFI mais rien ne change par défaut à ce sujet.
Internationalisation
Le gestionnaire d'entrée de saisie IBus passe à la version 1.5.30 ;
Mise à jour de ibus-anthy 1.5.16 pour la saisie du japonais.
Administration système
NetworkManager tente de détecter par défaut les conflits d'usage d'adresse IPv4 avec le protocole Address Conflict Detection avant de l'attribuer à la machine ;
NetworkManager va utiliser une adresse MAC aléatoire par défaut pour chaque réseau Wifi différent, et cette adresse sera stable pour un réseau donné. Cela permet de concilier vie privée et confort d'utilisation ;
Les unités système de systemd vont utiliser par défaut beaucoup d'options pour améliorer la sécurité des services ;
Les entrées des politiques SELinux qui font référence au répertoire /var/run font maintenant référence au répertoire /run ;
L'outil SSSD ne prend plus en charge les fichiers permettant de gérer les utilisateurs locaux ;
DNF ne téléchargera plus par défaut la liste des fichiers fournie par les différents paquets ;
L'outil fwupd pour mettre à jour les firmwares va utiliser passim comme cache pour partager sur le réseau local les métadonnées liées aux mises à jour disponibles pour les firmwares ;
Les systèmes Fedora Silverblue et Kinoite disposent de bootupd pour la mise à jour du chargeur de démarrage ;
Le paquet libuser est marqué en voie de suppression pour Fedora 41 alors que le paquet passwd est supprimé ;
Le paquet cyrus-sasl-ntlm a été supprimé ;
La gestion des droits utilisateurs pam_userdb passe de la base de données BerkeleyDB à GDBM ;
Le filtre antispam bogofilter utilise SQLite au lieu de BerkeleyDB pour gérer sa base de données interne ;
Le serveur LDAP 389 passe de la version 2.4.4 à la version 3.0.0 ;
Le paquet iotop est remplacé par iotop-c ;
L'orchestrateur de conteneurs Kubernetes évolue de la version 1.28 à la version 1.29 ;
Par ailleurs ses paquets sont restructurés ;
Pendant que podman est mis à jour vers la version 5 ;
Le paquet wget2 remplace le paquet wget en fournissant une nouvelle version ;
Le gestionnaire de base de données PostgreSQL migre vers sa 16e version ;
Les paquets MySQL et MariaDB sont remaniés et mis à jour vers la version 10.11.
Développement
Mise à jour de la suite de compilation GNU : GCC 14.0, binutils 2,41, glibc 2.39 et gdb 14.1 ;
La suite de compilateurs LLVM est mise à jour à la version 18 ;
Mise à jour de la bibliothèque C++ Boost à la version 1.83 ;
Le langage Go passe à la version 1.22 ;
Le JDK de référence pour Java passe de la version 17 à 21 ;
Mise à jour du langage Ruby 3.3 ;
Le langage PHP utilise la version 8.3 ;
La boîte à outils pour le machine learning PyTorch fait son entrée dans Fedora ;
Le paquet python-sqlalchemy utilise la nouvelle branche majeure 2.x du projet, le paquet python-sqlalchemy1.4 est proposé pour garder la compatibilité ;
La bibliothèque de validation des données Pydantic utilise dorénavant la version 2 ;
La bibliothèque Thread Building Blocks passe du fil 2020.3 au fil 2021.8 ;
La bibliothèque OpenSSL 1.1 est supprimée ne laissant que la dernière version de la branche 3.x ;
Les bibliothèques zlib et minizip utilisent leur variante zlib-ng et minizip-ng dorénavant ;
Le langage Python ne bénéficie plus de la version 3.7.
Projet Fedora
L'édition Cloud sera construite avec l'utilitaire Kiwi dans Koji ;
Tandis que l'édition Workstation aura son ISO générée avec l'outil Image Builder ;
L'image minimale ARM sera construite avec l'outil OSBuild ;
Il bénéficiera également des images Simplified Provisioning ;
Et le tout sera construit en utilisant rpm-ostree unified core ;
Fedora sera construit avec DNF 5 en interne ;
Les macros forge passent du paquet redhat-rpm-config à forge-srpm-macros ;
La construction des paquets échouera si l'éditeur de lien détecte certaines classes de vulnérabilité dans le binaire en construction ;
Phase 3 de l'usage généralisé des noms abrégés de licence provenant du projet SPDX pour la licence des paquets plutôt que des noms du projet Fedora ;
Clap de fin pour la construction des mises à jour au format Delta RPM ;
Suite du projet de ne générer les JDKs qu'une fois, et les rempaqueter ainsi à toutes les variantes du système ;
Compilation des paquets en convertissant plus d'avertissements comme erreurs lors de la compilation des projets avec le langage C ;
Les images immuables comme Silverblue seront nommées sous la dénomination Atomic pour éviter la référence au terme immuable qui est confus pour les utilisateurs.
Tester
Durant le développement d'une nouvelle version de Fedora Linux, comme cette version Beta, quasiment chaque semaine le projet propose des journées de tests. Le but est de tester pendant une journée une fonctionnalité précise comme le noyau, Fedora Silverblue, la mise à niveau, GNOME, l’internationalisation, etc. L'équipe d'assurance qualité élabore et propose une série de tests en général simples à exécuter. Suffit de les suivre et indiquer si le résultat est celui attendu. Dans le cas contraire, un rapport de bogue devra être ouvert pour permettre l'élaboration d'un correctif.
C'est très simple à suivre et requiert souvent peu de temps (15 minutes à une heure maximum) si vous avez une Beta exploitable sous la main.
Si l'aventure vous intéresse, les images sont disponibles par Torrent ou via le site officiel.
Si vous avez déjà Fedora Linux 39 ou 38 sur votre machine, vous pouvez faire une mise à niveau vers la Beta. Cela consiste en une grosse mise à jour, vos applications et données sont préservées.
Nous vous recommandons dans les deux cas de procéder à une sauvegarde de vos données au préalable.
When working with larger data structures in Nushell, there are often tables that are wider than the terminal has width, resulting in some columns truncated, indicated by the three dots .... But how can we expand the dots?
The answer is simple, but surprisingly, not easily found. The “Working with tables” documentation of Nushell weirdly doesn’t tell, for example. The trick is to use the command columns to get a list of all column names:
Please join us at the next regular Open NeuroFedora team meeting on Monday 25 March at 1300 UTC.
The meeting is a public meeting, and open for everyone to attend.
You can join us in the Fedora meeting channel on chat.fedoraproject.org (our Matrix instance).
Note that you can also access this channel from other Matrix home severs, so you do not have to create a Fedora account just to attend the meeting.
You can use this link to convert the meeting time to your local time.
Or, you can also use this command in the terminal:
$date-d'Monday, March 25, 2024 13:00 UTC'
The meeting will be chaired by @Penguinpee.
The agenda for the meeting is:
Josh and Kurt talk about the new SSDF attestation form from CISA. The current form isn’t very complicated, and the SSDF has a lot of room for interpretation. But this is the start of something big. It’s going to take a long time to see big changes in supply chain security, but we’re confident they will come.
This is part 5 of a multi-part series. See part 1
for the beginning of the series.
Cloning hard drives with dd_rescue
In cases where a hard drive is failing, often simply cloning the drive is all that is required to recover data.
There are many other situations where cloning a drive is important though, such as when attempting to
recover from a broken partition table or major filesystem corruption.
The primary tool for cloning drives is called dd_rescue.
Running dd_rescue -h
or simply dd_rescue
with no options will give you a summary of the various command-line options:
dd_rescue Version 1.14, garloff@suse.de, GNU GPL
($Id: dd_rescue.c,v 1.59 2007/08/26 13:42:44 garloff Exp $)
dd_rescue copies data from one file (or block device) to another.
USAGE: dd_rescue [options] infile outfile
Options: -s ipos start position in input file (default=0),
-S opos start position in output file (def=ipos),
-b softbs block size for copy operation (def=65536),
-B hardbs fallback block size in case of errs (def=512),
-e maxerr exit after maxerr errors (def=0=infinite),
-m maxxfer maximum amount of data to be transfered (def=0=inf),
-y syncfrq frequency of fsync calls on outfile (def=512*softbs),
-l logfile name of a file to log errors and summary to (def=""),
-o bbfile name of a file to log bad blocks numbers (def=""),
-r reverse direction copy (def=forward),
-t truncate output file (def=no),
-d/D use O_DIRECT for input/output (def=no),
-w abort on Write errors (def=no),
-a spArse file writing (def=no),
-A Always write blocks, zeroed if err (def=no),
-i interactive: ask before overwriting data (def=no),
-f force: skip some sanity checks (def=no),
-p preserve: preserve ownership / perms (def=no),
-q quiet operation,
-v verbose operation,
-V display version and exit,
-h display this help and exit.
Note: Sizes may be given in units b(=512), k(=1024), M(=1024^2) or G(1024^3) bytes
This program is useful to rescue data in case of I/O errors, because
it does not necessarily abort or truncate the output.
Note that there is also a GNU ddrescue with a similar feature set, but with entirely incompatible command-line arguments.
In
the simplest of cases, dd_rescue
can be used to copy infile
(let's say, for example, /dev/sda) to outfile
(again, for example, /dev/sdb).
dd_rescue /dev/sda /dev/sdb
In most cases, you'll want a little more control over how dd_rescue behaves though.
For example, to clone failing /dev/sda to /dev/sdb:
dd_rescue -d -D -B 4k /dev/sda /dev/sdb
(to use the default 64k block size) or, for really bad drives, to force only one read attempt:
dd_rescue -d -D -B 4k -b 4k /dev/sda /dev/sdb
Adding the -r option to read backwards also helps sometimes.
Changing block sizes
By default, dd_rescue
uses a block size of 64k (overridden with -b). In the event of a read error, it tries to read
again in 512-byte chunks (overridden with -B). If a drive is good (or only beginning to fail), a
larger block size (usually in the 512kB-1MB range) will give you significantly better performance.
If a drive is failing, forcing the default block size to the same value as the fall-back size will keep
dd_rescue
from re-reading (and therefore possibly damaging) failed blocks.
Direct I/O
The -d and -D options turn on direct I/O for the input and output files respectively. Direct I/O turns
off all OS caching, both read-ahead and write-behind. This is much
more efficient (and safer) when reading from and writing to hard drives, but should generally be avoided
when using regular files.
Other useful options
-r Read backwards. Sometimes works more reliably. (Very handy trick...)
-s num Start position in input file.
-S num Start position in output file. (Defaults to the same as -s.)
-e num Stop after num errors.
-m num Maximum amount of data to read.
-l file Write a log to file.
Copying partitions
Let's say you have a drive with a MS-DOS partition table. The drive has two partitions. The first is a NTFS partition that seems to be intact. The second partition is an unknown type. Rather than copying every block using dd_rescue, you want to copy only the blocks that are in use to a drive that is the same size.
To do this, first copy the boot sector and partition table from /dev/sda
to /dev/sdb using dd:
dd if=/dev/sda of=/dev/sdb count=1
The default block size of dd is
512 bytes, which, conveniently, is the size of boot sector + partition table at the beginning of the
drive.
Note: This trick doesn't quite work on MS-DOS partition tables with extended partitions!
In that case, use sfdisk to copy the partition table (after running the above command to pick up the boot sector):
sfdisk
-d /dev/sda | sfdisk /dev/sdb
Next, re-read the partition table on /dev/sdb using hdparm:
hdparm
-z /dev/sdb
Next we can clone the NTFS filesystem on /dev/sda1 to /dev/sdb1 using the ntfsclone command from ntfsprogs:
ntfsclone
--rescue -O /dev/sdb1 /dev/sda1
Finally we clone /dev/sda2 to /dev/sdb2 using dd_rescue using a 1MB block size (for speed):
The story of Hitler's regime ending in a bunker in Berlin is well known.
In the German language, the bunker is known as the
Fuhrerbunker.
The bunker was constructed in two stages. It was built underground.
The roof of the deeper bunker was eight meters below ground and three meters
thick reinforced concrete.
Most of the bunker was demolished in the late 1980s around the time
the Berlin Wall came down.
Hitler spent very little time in Berlin during the war. As the Allies
closed in from the west and the Soviets closed in from the east, Hitler
returned to Berlin and took up residence in the bunker in January 1945.
On 1 April 1945, Hitler moved the functions of Government from the
Reich Chancellery, which was above ground, down into the bunker proper.
This was the beginning of the final chapter for the Nazi regime.
At the beginning of April 2016, Matthias Kirschner and Jonas Oberg
closed down the FSFE-Buro (office) in Dusseldorf. They rented a van
to pack up all the contents of the Dusseldorf office and retreat back
to Berlin. They had booked two nights hotel accommodation in
Dusseldorf so they could wind up the office smoothly.
Things didn't go exactly to plan. The FSFE Fellows in Dusseldorf
heard about this plan and scheduled an Extraordinary General Meeting (EGM)
to take place on the evening of Monday, 4 April 2016.
Kirschner and Oberg canceled their accommodation in the hotel and
hotfooted it back to Berlin in a very hasty retreat.
There is one staff member who had been employed at the FSFE-Buro
Dusseldorf for many years, Rainer Kersten. Working for an organization
associated with the name of the real FSF and Dr Richard Stallman must
have given him great pride. But Matthias Kirschner is not
Dr Richard Stallman. German employees have certain expectations about
the security of their employment and they can't simply be discarded
on a whim. Kirschner, being a German too, would surely realize that.
An FSFE web page snapshot from 22 March 2016 includes Rainer
Kersten's name. His name appears in the next snapshot on 11 April.
The subsequent snapshot, on 31 July 2016,
Rainer Kersten is gone.
The exact day that Kirschner shuttered the FSFE-Buro Dusseldorf,
4 April, is the anniversary of the day the Soviet KGB finally disposed
of the remains of Hitler and Goebels. On 4 April 1970, KGB agents
exhumed the coffins, removed the bones and whatever human remains were
left, incinerated them and then disposed of the ashes in a river.
When the FSFE council
canceled the elections in 2018, the last Fellowship representative
made a point of telling them they were behaving like cowards.
Subject: Re: [GA] Fwd: Re: Minutes from our extraordinary assembly
Date: Wed, 30 May 2018 20:41:44 +0100
From: Fellowship Representative elected by Community
To: ga@lists.fsfe.org
On 30/05/18 20:36, Heiki Lõhmus wrote:
> Dear [Representative of the Community],
>
>> In that case, can you please send the information to the GA list so all
>> members are aware of it?
> I can not as no record of individual votes exists.
Heiki, if you can't remember how people voted on such a toxic matter
just 4 days ago then are you competent to remain in council?
Or are you just being a coward?
Looking at the
minutes of the annual general meeting in 2021, we see a mysterious
discussion about "insurances of the association". It is not clear what
risks they are insuring against but it smells like a situation where they
know they've been pissing people off for years and now they have become
preoccupied with insurance and security in much the same way that Hitler
became preoccupied with his reinforced concrete bunker.
They pissed off the Dusseldorf community and ran away from an
Extraordinary General Meeting on 4 April 2016.
I've started creating this page to keep track of the kill money
that I feel Google is laundering through the
bank accounts of Software in the Public Interest, Inc
and the Debian "Project". This page may
be updated from time to time as more of this dirty money is uncovered.
I completely resigned from the organization in September 2018.
After my resignation, the Googlists have attacked my family
constantly with a campaign of online harassment.
Here I look at the money Googlists paid for these attacks and I
contrast that against money that these Googlists have refused to
pay in other situations.
Subject: Re: Death of Adrian von Bidder
Date: Thu, 21 Apr 2011 08:56:04 +0200
From: Andreas Tille <andreas@an3as.eu>
To: debian-private@lists.debian.org
... [snip] ...
The donators of the Debian project intend to spend money for the
development of the Debian project. If we spend Debian money for a
wreath (or any form of replacement donation) this is not related to the
development of Debian. It is rather *us* *people* who say goodby to
a friend. So the money should not come from project funds but rather
from single developers.
Saying this I would like to vote against spending Debian money but
rather doing a separate collection. I could live with some kind of "de
facto" collection like this: I will ask for Debian money for DebConf.
In case Debian project money is really spended for Adrian's funeral I'd
simply ask for 10Euro less than I would have done otherwise.
... [snip] ...
In the end, individual donors contributed approximately CHF 682.78
to AMICA Schweiz, a charity supported by von Bidder's family. Not
one Swiss Franc was contributed from Debian itself.
They couldn't pay for a wreath for Adrian von Bidder, despite
the fact he was an officer of the association.
They couldn't pay for casual staff to wash dishes.
They had CHF 38,000 leftover at the end.
This money was kept in reserve for future vendettas.
Subject: Call for ideas -- useful ways of spending Debian money
Date: Tue, 1 Oct 2013 21:46:17 +0200
From: Lucas Nussbaum <leader@debian.org>
To: debian-private@lists.debian.org
CC: auditor@debian.org, philipp@hug.cx
[ TL;DR: ETOO_MUCH_MONEY -- need ideas to flush queue ]
Hi,
Thanks to the fantastic work of the DebConf13 sponsorship (fundraising)
team, DebConf13 generated a surplus. The current estimate of it is CHF 38k (that's USD 42k, or EUR 31k). That's excellent news.
The not-so-excellent news is that it means that the debconf13
association will have to pay income taxes for it. (no estimate yet;
Philipp Hug (DC13 and debian.ch treasurer) will get in touch with a tax
expert).
Even if Switzerland has been very welcoming towards Debian, it would not
be a bad idea to try to avoid paying too much taxes. A good way to do
that is to spend some of the surplus (in ways useful to Debian, of
course).
Could you start thinking of useful ways to spend some money? servers?
porter boxes? buildds? sprints? Of course, it would need to be spent before
the end of 2013. There are no known restrictions on what we can buy or
where we can ship. What we end up buying will of course be made public
as usual. To move forward, please reply to this mail, providing an
estimate and a justification. Or mail leader@ + auditor@ if you prefer.
Somehow related: we are participating in GNOME's Outreach Program for
Women, winter edition[1].
As already stated in April[2], I wouldn't favor a situation where Debian
funds are used to pay OPW participation on a regular basis. However, as
an experiment, it makes sense to help that happen for the first time (it
didn't happen in the summer edition).
So, if the fundraising effort currently being set up fails to raise
enough money for one stipend, but still raises a significant amount of
money, I will authorize the use of Debian money for the difference
(likely for at most $2900 -- that's half the stipend, so the other half
needs to come from fundraising).
[1] https://lists.debian.org/debian-women/2013/09/msg00058.html
[2] https://lists.debian.org/debian-project/2013/04/msg00108.html
Q: Why is this on -private@?
A: Because I'm not sure yet how cautious we need to be about the DC13
surplus situation. Better safe than sorry. We can restart the
discussion on a public list when/if things are cleared.
Thanks,
Lucas
Google sent this money into Debian bank accounts. I never received
any recognition for my own efforts as a mentor between 2013 and 2018.
Subject: Re: Payment Instructions for GSoC 2018 Organizations
Date: Tue, 18 Sep 2018 11:39:41 +0200
From: Martin Michlmayr <tbm@cyrius.com>
To: Molly de Blanc <deblanc@riseup.net>
CC: Daniel Pocock <daniel@pocock.pro>, treasurer@debian.org, outreach@debian.org, treasurer@spi-inc.org
This is just to let you know that we're about to receive the
funds from Google for GSoC 2018.
2. Debian Project - $17,200
(note: this is more than you should get according to my calculation,
but maybe I'm wrong:
>>> 2200 + 500 + 500 * 26
15700
I guess you're getting 4x the student travel scholarship
)
Payment for each organization includes:
* Student stipends ($500 per student developer)
* Mentor summit stipend ($2200)
* Student travel scholarship ($500)
* Deductions for missing evaluations ($1100 per evaluation missed)
Martin
Subject: Realizing Good Ideas with Debian Money
Date: Wed, 29 May 2019 07:49:25 -0400
From: Sam Hartman
Reply-To: debian-project@lists.debian.org
To: Mo Zhou
CC: Andrey Rahmatullin , debian-devel@lists.debian.org, debian-project@lists.debian.org
[moving a discussion from -devel to -project where it belongs]
>>>>> "Mo" == Mo Zhou writes:
Mo> Hi,
Mo> On 2019-05-29 08:38, Raphael Hertzog wrote:
>> Use the $300,000 on our bank accounts?
So, there were two $300k donations in the last year.
One of these was earmarked for a DSA equipment upgrade.
DSA has a couple of options to pursue, but it's possible they may
actually spend $400k on an equipment refresh.
$200k doesn't really go that far in terms of big infrastructure projects
like bikeshed or similar.
I'm looking for someone who would be willing to guide a discussion of
the Money issues Martin brought up in his campaign. I don't have time
to guide that effor myself. Real thought needs to be put into it; it
will be at least as much work as the discussions I'm leading on
packaging practices and git if done correctly.
However it could be very valuable for the project.
--Sam
Subject: Bits from the DPL (December 2018)
Date: Mon, 31 Dec 2018 14:36:49 +0000
From: Chris Lamb <lamby@debian.org>
To: debian-devel-announce@lists.debian.org
... [snip] ...
* Acted a central contact point connecting the various parties
involved in receiving a significant donation to Debian from their
Open Source office [14].
Thank you in particular to Cat Allman for making this happen. :)
... [snip] ...
[14] https://opensource.google.com/
... [snip] ...
The OSI President and Google
One of our collaborators in Google Summer of Code (GSoC) was the
OSI President, Molly de Blanc.
At the end of 2018, de Blanc traveled to the GSoC Mentor Summit
and had discussions (received orders) from Google.
The OSI President appeared again at FrOSCon a few months later
where she promoted pushing people.
WIPO payment in 2022
Here is the money sent to WIPO to censor a web site.
Tribunal of Vaud, Switzerland, February 2023
Here is one of the payments made to the cantonal tribunal in the
Canton of Vaud, Switzerland, begging the judge to denounce my company
the Software Freedom Institute.
Expenses processed by Software in the Public Interest, Inc
The total of these payments for the period January 2019 to January 2023
is $USD 120,843.26
They couldn't find CHF 200 to buy a wreath for Adrian von Bidder in
Basel. They couldn't pay the casual workers to wash the dishes at DebConf13
in Vaumarcus. But they found $USD 120,843.26 to pay the lawyers.
Use of more Debian.ch funds
The reports don't show any more transactions after January 2023. Did
they use the Debian.ch bank account in
Switzerland to make the subsequent payments?
Software in the Public Interest, Inc, charges a 5% handling fee
When Google and other companies pay money into the account,
Software in the Public Interest, Inc,
charges a 5% handling fee.
Therefore, to pay $120,843.26 to the lawyers, Google has to deposit
$128,000.
Any new technology requires a mental effort to understand. When trying to automate the boring stuff, one decision I have to make is whether to use straight shell scripting or whether to perform that operation using Ansible. What I want to do is look at a simple Ansible playbook I have written, and then compare what the comparable shell script would look like to determine if it would help my team to use Ansible or not in this situation.
The activity is building a Linux Kernel that comes from a series of topic branches applied on top of a specific upstream version. The majority of the work is done by a pre-existing shell script, so what we mostly need to do is git work. Here is an annotated playbook. After each play, I note what it would take to do that operation in shell.
---
- name: Build a kernel out of supporting branches
hosts: servers
remote_user: root
vars:
#defined in an external vars file so we can move ahead
#kernel_version:
#soc_id:
test_dir: /root/testing
linux_dir: "{{ test_dir }}/linux"
tools_dir: "{{ test_dir }}/packaging"
tasks:
- name: ssh key forwarding for gitlab
ansible.builtin.copy:
src: files/ssh.config
dest: /root/.ssh/config
owner: root
group: root
mode: '0600'
backup: no
#scp $SRCDIR/files/ssh.config $SSH_USER@SSH_HOST:/root/.ssh/ssh.config
#ssh $SSH_USER@SSH_HOST chmod 600/root/.ssh
#ssh $SSH_USER@SSH_HOST chown root:root /root/.ssh/ssh.config
- name: create testing dir
ansible.builtin.file:
path: /root/testing
state: directory
#ssh $SSH_USER@SSH_HOST mkdir -p /root/testing
- name: Install Build Tools
ansible.builtin.yum:
name: make, gcc, git, dwarves, openssl, grubby, rpm-build, perl
state: latest
#ssh $SSH_USER@SSH_HOST yum -y install make, gcc, git, dwarves, openssl, grubby, rpm-build, perl
- name: git checkout Linux Kernel
ansible.builtin.git:
repo: git@gitlab.com:{{ GIT_REPO_URL }}/linux.git
dest: /root/testing/linux
version: v6.5
#This one is a bit more complex, as it needs to check if the repo already
#exists, and, if so, do a pull, otherwise do a clone.
- name: add stable stable Linux Kernel repo
ansible.builtin.command: git remote add stable https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
changed_when: false
args:
chdir: /root/testing/linux
ignore_errors: true
#there should be and Ansible git command for adding an additional remote.
#I could not find it, so I resported to command.
#This is identical to running via ssh
- name: fetch stable stable Linux Kernel repo
ansible.builtin.command: git fetch stable
args:
chdir: /root/testing/linux
#Same issue as above. This shows that, when an Ansible command is
#well crafted, it can link multiple steps into a single command, reduce the #need for an additional ssh-based command.
- name: git checkout gen-early-patches
ansible.builtin.git:
repo: git@gitlab.com:{{ GIT_REPO_URL }}/packaging.git
dest: "{{ tools_dir }}"
version: main
#same issue as with the clone for the Linux Kernel repository
- name: generate early kernel patches
ansible.builtin.shell:
cmd: "{{tools_dir }}/git-gen-early-patches.sh {{ tools_dir }}/gen-{{ soc_id }}-{{ kernel_version }}-general.conf"
chdir: /root/testing/linux
#One benefit to running with Ansible is that it will automatically
#wrap a shell call like this with an error check. This cuts dowm
#on boilerplate code and the potential to miss one.
- name: determine current patch subdir
ansible.builtin.find:
paths: /root/testing/linux
use_regex: true
#TODO build this pattern from the linux kernel version
pattern: ".*-v6.7.6-.*"
file_type: directory
register: patch_directory
#This would probably be easier to do in shell:
#BUILD_CMD=$( find . -name ".*-v6.7.6-.*/build.sh" | sort | tail -1 )
#
- ansible.builtin.debug:
msg: "{{ patch_directory.files | last }}"
- set_fact:
patch_dir: "{{ patch_directory.files | last }}"
- ansible.builtin.debug:
msg: "{{ patch_dir.path }}/build.sh"
- name: build kernel
ansible.builtin.shell:
cmd: "{{ patch_dir.path }}/build.sh"
chdir: /root/testing/linux
#Just execute the value of BUILD_CMD
#ssh $SSH_USER@SSH_HOST /root/testing/linux/$BUILD_CMD
So, should this one be in Ansible or shell? It is a close call. Ansible makes it hard to do shell things, and this needs a bunch of shell things. But Ansible is cleaner in doing stuff on a remote machine from a known starting machine, which is how this is run: I keep the Ansible playbook on my Laptop, connect via VPN, and run the playbook on a newly provisioned machine, or rerun it on a machine while we are in the process of updating the Kernel version, etc.
This use case does not make use of one of the primary things that Ansible is very good at doing: running the same thing on a bunch of machines at the same time. Still, it shows that Ansible is at least worth evaluating if you are running a workflow that spans two machines, and has to synchronize state between them. For most tasks, the Ansible play will be sufficient, and falling back to Shell is not difficult for most other tasks.
After you get something working, you find you might have missed a step in documenting how you got that working. You might have installed a package that you didn’t remember. Or maybe you set up a network connection. In my case, I find I have often brute-forced the SSH setup for later provisioning. Since this is done once, and then forgotten, often in the push to “just get work done” I have had to go back and redo this (again usually manually) when I get to a new machine.
To avoid this, I am documenting what I can do to get a new machine up and running in a state where SSH connections (and forwarding) can be reliably run. This process should be automatable, but at a minimum, it should be understood.
To start with, I want to PXE boot the machine, and reinstall the OS. Unless you are using a provisioning system like Ironic or Cobbler, this is probably a manual process. But you still can automate a good bit of it. The first step is to tell the IPMI based (we are not on Red Fish yet) BMC to boot to PXE upon the next reboot.
This is the first place to introduce some automation. All of our ipmitool commands are going to take the majority of the same parameters. So we can take the easy step of creating a variable for this command, and use environmental variables to fill in the repeated values.
One benefit of this is that you can now extract the variables into an environment variable file that you source separate from the function. That makes this command reusable for other machines.
To require PXE booting on the next pass we also make use of a function that can be used to power cycle the system. Note that I include a little bit of feedback in the commands I use so that the user does not get impatient.
Once this function is executed, the machine will boot to PXE mode. What this looks like is very dependent on your setup. There are two things that tend to vary. One is how you connect to the machine in order to handle the PXE setup. If you are lucky, you have a simple interface. We have a serial console concentrator here, so I can connect to the machine using a telnet command: I get this command from our lab manager. IN other stages of life, I have had to use minicom to connect to a physical UART (serial port) to handle PXE boot configuration. I highly recommend the serial concentrator route if you can swing it.
But usually you have an IPMI based option to open the serial console. Just be ware that this might conflict with, and thus disable, a UART based way of connecting. For me, I can do this using:
$CMD_IPMITOOL sol activate
The other thing that varies is your PXE set up. We have a PXE menu that allows us to select between many different Linux distributions with various configurations. My usual preference is to do a minimal install, just enough to get the machine up and on the network accessible via SSH. This is because I will almost always do an upgrade of all packages (.deb/.rpm) on the system once it is booted. I also try to make sure I don’t have any major restrictions on disk space. Some of the automated provisioning approaches make the Root filesystem or the home filesystem arbitrarily small. For development, I need to be able to build a Linux Kernel and often a lot of other software. I don’t want to run out of disk space. A partitioning scheme that is logical for a production system may not work for me. My Ops team provides and option that has Fedora 39 Server GA + Updates, Minimal, Big Root. This serves my needs.
I tend to reuse the same machines, and thus have ssh information in the files under ~/.ssh/known_hosts. After a reprovision, this information is no longer accurate, and needs to be replaced. In addition, the newly provisioned machine will not have an ssh public key on it that corresponds with my private Key. If only they used FreeIPA…but I digress…
If I try to connect to the reprovisioned machine:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:EcPh9oazsjRaC9q8fJqJc8OjHPoF4vtXQljrHJhKDZ8.
Please contact your system administrator.
Add correct host key in /home/ayoung/.ssh/known_hosts to get rid of this message.
Offending ED25519 key in /home/ayoung/.ssh/known_hosts:186
remove with:
ssh-keygen -f "/home/ayoung/.ssh/known_hosts" -R "10.76.111.73"
Host key for 10.76.111.73 has changed and you have requested strict checking.
Host key verification failed.
#Only run this once per provisioning
dev_prep_ssh(){
ssh-keygen -R $DEV_SYSTEMIP
ssh-copy-id -o StrictHostKeyChecking=no root@$DEV_SYSTEMIP
ssh-keyscan gitlab.com 2>&1 | grep -v \# | ssh root@$DEV_SYSTEMIP "cat >> .ssh/known_hosts"
}
The first two could be done via Ansible as well. I need to find a better way to do the last step via Ansible (line_in_file seems to be broken by this), or to bash script it so that it is idempotent.
On GNOME Firefox runs with disabled system titlebar by default. It saves horizontal space on wide screens but also removes control over window, traditionally provided by Window manager and desktop environment.
GNOME allows to set titlebar actions by gnome-tweaks tool, you can define window actions for double click by first mouse button, middle click and secondary button. These choices are not followed by Firefox if system titlebar is off because Firefox integrates titlebar with browser tab strip and performs build-in tasks like open/close new tab or toggle maximize.
However Firefox 124 improves it and follows mouse button double click action defined by GNOME so you change it as you wish.
You also can define titlebar action for middle mouse button click, which opens a new tab by default. Set widget.gtk.titlebar-action-middle-click-enabled at about:config and it should work then.
This is an independent, censorship-resistant site run by volunteers. This site and the blogs of individual volunteers are not officially affiliated with or endorsed by the Fedora Project.
— enquanto executava uma façanha sem precedentes: tocar todos os 5 concertos de piano de Rachamninoff em uma única apresentação de mais de 4 horas de duração. Mediram também a frequência cardíaca do regente 
The Fedora 39, 40, EL-8 and EL-9 packages (modules and SCL) are available for x86_64 and aarch64.
These Versions fix 3 security bugs (CVE-2024-2756, CVE-2024-3096 and CVE-2024-2757), so update is strongly recommended.
Here are some stats from FAW 2023:
You can check out all the articles highlighting what happened during FAW:
︎
I hope you all have had a good (and drier) week so far and enjoy your weekend, and if you would like some weekend reading, weekend bug fixing, or even a weekend proposal writing session, read on for the links and information you need to do just that 
We ran a few raffles and wrapped up as well.
