Fedora is a Trademark of Red Hat, Inc, an operating system built by volunteers around the world. This page is provided so that independent volunteers can showcase our contributions to Fedora and Free Software in general. Official Fedora Download page.

RSS Atom

We Make Fedora

February 11, 2025

• Kushal Das Using openpgp-card-tool-git with git

  One of the power of Unix systems comes from the various small tools and how they work together. One such new tool I am using for some time is for git signing & verification using OpenPGP and my Yubikey for the actual signing operation via openpgp-card-tool-git. I replaced the standard gpg for this usecase with the oct-git command from this project.

  Installation & configuration

  cargo install openpgp-card-tool-git
  

  Then you will have to configuration your (in my case the global configuration) git configuration.

  git config --global gpg.program <path to oct-git>
  

  I am assuming that you already had it configured before for signing, otherwise you have to run the following two commands too.

  git config --global commit.gpgsign true
  git config --global tag.gpgsign true
  

  Usage

  Before you start using it, you want to save the pin in your system keyring.

  Use the following command.

  oct-git --store-card-pin
  

  That is it, now your git commit will sign the commits using oct-git tool.

  In the next blog post I will show how to use the other tools from the author for various different OpenPGP oeprations.

February 10, 2025

• Swiss JuristGate Unredacted FINMA judgment into Parreaux, Thiébaud & Partners / Justicia SA [TOP SECRET]

  In September 2023, Gaelle Jeanmonod at FINMA published a summary of the judgment against Parreaux, Thiébaud & Partners and their successor Justicia SA.

  Madame Jeanmonod redacted the name of the company, the dates and other key details. We have recreated the unredacted judgment.

  Many paragraphs are missing. The document released by Madame Jeanmonod only includes paragraphs 55 to 65 and the paragraph 69.

  Some entire sentences appear to be missing and replaced with the symbol (...).

  Details about the original publication on the FINMA site.

  

   

  Key to symbols:

  Symbol	Meaning
  PTP	Parreaux, Thiébaud & Partners
  A	Mathieu Parreaux
  X	Parreaux, Thiébaud & Partners
  Y	Justicia SA

  Important: we recommended reading together with the full chronological history published in the original blog post by Daniel Pocock.

  Provision of insurance services without autorisation

  Judgment of the financial markets regulator FINMA de 2023

  Summary

  Following numerous reports that Parreaux, Thiébaud & Partners was operating an insurance business without authorisation, FINMA conducted investigations that led to the opening of enforcement proceedings. In fact, Parreaux, Thiébaud & Partners offered legal subscriptions for companies and individuals, which provided unlimited access to various legal services for an annual fee. In addition, Parreaux, Thiébaud & Partners also financed, in certain situations, advances on costs to pay lawyers' and court fees in the form of a loan at a 0&percnt interest rate. According to its general terms and conditions, Parreaux, Thiébaud & Partners then obtained reimbursement of this loan from the legal costs to be received at the end of the proceedings in the event of victory. In the event of loss, the balance constituted a non-repayable loan. With regard to the areas of law that were partially covered and to disputes prior to the signing of the contract, the claim was partially covered by 50&percnt.

  During the procedure, FINMA appointed an investigation officer within Parreaux, Thiébaud & Partners. While the investigation officer's work had already begun, the activities of Parreaux, Thiébaud & Partners were taken over by Justicia SA in [late 2021 or early 2022]. From that point on, Parreaux, Thiébaud & Partners ceased its activities for new clients. Clients who had taken out a subscription with Parreaux, Thiébaud & Partners prior to the month of (…) were informed when renewing their subscription that their subscription had been transferred to Justicia SA. FINMA then extended the procedure and the mandate of the investigation officer to the latter. The business model of Justicia SA is almost identical to that of Parreaux, Thiébaud & Partners. The main difference concerns the terms of repayment of the loan which, according to the general terms and conditions of Justicia SA, was also repayable in the event of defeat according to the "terms agreed between the parties".

  The report of the investigating officer contains in particular a detailed analysis of the activity of the two companies as well as a sample examination of client files.

  By decision of [April?] 2023, FINMA held that the conditions set by case law to qualify an insurance activity were met and therefore found that Parreaux, Thiébaud & Partners, Justicia SA as well as Mathieu Parreaux, managing partner of Parreaux, Thiébaud & Partners and director of Justicia SA, carried out an insurance activity without having the required authorisation.

  FINMA then found that Parreaux, Thiébaud & Partners, Justicia SA and Mathieu Parreaux had carried out insurance activities without the necessary authorisation, appointed a liquidator and ordered the immediate liquidation of the two companies. FINMA also ordered the confiscation of the liquidation proceeds in favour of the Confederation, ordered Mathieu Parreaux to refrain from carrying out, without the necessary authorisation, any activity subject to authorisation under the financial market laws and published the order to refrain for a period of 2 years on its website.

  Key points from the judgment

  (…)

  1. Engaging in insurance transactions without the right to do so

  (55) The LSA is intended in particular to protect policyholders against the risks of insolvency of insurance companies and against abuse². Insurance companies established in Switzerland that carry out direct insurance or reinsurance activities must first obtain authorisation from FINMA and are subject to its supervision³. Where special circumstances justify it, FINMA may release from supervision an insurance company for which the insurance activity is of little economic importance or only affects a limited circle of policyholders⁴.

  (56) In accordance with Art. 2 para. 4 LSA, it is up to the Federal Council to define the activity in Switzerland in the field of insurance. In an ordinance dated 9 November 2005, the Federal Council clarified that, regardless of the method and place of conclusion of the contract, there is an insurance activity in Switzerland when a natural or legal person domiciled in Switzerland is the policyholder or insured⁵. Furthermore, the LSA applies to all insurance activities of Swiss insurance companies, both for insurance activities in Switzerland and abroad. Thus, even insurance contracts concluded from Switzerland but which relate exclusively to risks located abroad with policyholders domiciled abroad are subject to the LSA. In such cases, there may also be concurrent foreign supervisory jurisdiction at the policyholder's domicile⁶.

  (57) Since the legislature did not define the concept of insurance, the Federal Court developed five cumulative criteria to define it⁷: the existence of a risk, the service provided by the policyholder consisting of the payment of a premium, the insurance service, the autonomous nature of the transaction and the compensation of risks on the basis of statistical data. It is appropriate to examine below whether the services provided by Parreaux, Thiébaud & Partners and Justicia SA respectively meet the criteria of the given definition of the insurance activity.

  (58) The existence of a risk: this is the central element for the qualification of insurance. The object of an insurance is always a risk or a danger, i.e. an event whose occurrence is possible but uncertain. The risk or its financial consequences are transferred from the insured to the insurer⁸. The uncertainty assumed by the insurer typically consists of determining whether and when the event that triggers the obligation to pay benefits occurs. The uncertainty can also result from the consequences of an event (already certain)⁹. In a judgment of 21 January 2011, the Federal Court, for example, acknowledged that the rental guarantee insurer who undertakes to pay the lessor the amount of the rental guarantee in place of the tenant while reserving the right to take action against the latter to obtain reimbursement of the amount paid, bears the risk of the tenant's insolvency. Thus, the risk of non-payment by the tenant is sufficient in itself to qualify this risk as an insurance risk¹⁰.

  (59) In this case, the purpose of the legal subscriptions offered by Parreaux, Thiébaud & Partners / Justicia SA is the transfer of a risk from the clients to Parreaux, Thiébaud & Partners / Justicia SA. Indeed, when the client concludes a legal subscription, Parreaux, Thiébaud & Partners / Justicia SA assumes the risk of having to provide legal services and bear administrative costs, respectively lawyers' fees, court fees or expert fees incurred by legal matters. When a client reports a claim, Parreaux, Thiébaud & Partners / Justicia SA bears the risk and therefore the financial consequences arising from the need for legal assistance in question. In cases where there is a claim prior to the conclusion of the subscription, Parreaux, Thiébaud & Partners / Justicia SA will cover 50&percnt of the costs for this claim, but will continue to bear the risk for any future disputes that may arise during the term of the subscription. In this sense, Parreaux, Thiébaud & Partners / Justicia SA provide services that go beyond those offered by traditional legal protection insurance, which, however, has no influence on the existence of an uncertain risk transferred to Parreaux, Thiébaud & Partners / Justicia SA upon conclusion of the subscription. Furthermore, it was found during the investigation that, in at least one case, Parreaux, Thiébaud & Partners covered the fees without entering into a loan agreement with the client; it was therefore not provided for these advances to be repaid, contrary to what was provided for in the general terms and conditions of Parreaux, Thiébaud & Partners. Furthermore, it could not be established that the new wording of the general terms and conditions of Justicia SA providing for the repayment of the loan regardless of the outcome of the proceedings had been implemented. To date, no loan has been repaid. These elements allow us to conclude that the risk of having to pay for legal services and advances on fees are borne by Parreaux, Thiébaud & Partners and Justicia SA in place of the clients. Finally, in accordance with the case law of the Federal Court, even if the loan granted by Justicia SA is accompanied by an obligation to repay, the simple fact of bearing the risk of insolvency of its clients is sufficient to justify the classification of insurance risk.

  (60) The insured's benefit (the premium) and the insurance benefit: In order to qualify a contract as an insurance contract, it is essential that the policyholder's obligation to pay the premiums is offset by an obligation on the part of the insurer to provide benefits. The insured must therefore be entitled to the insurer's benefit at the time of the occurrence of the insured event¹¹. To date, the Federal Court has not ruled on the question of whether the promise to provide a service (assistance, advice, etc.) constitutes an insurance benefit. However, recent doctrine shows that the provision of services can also be considered as insurance benefits. Furthermore, this position is confirmed and defended by the Federal Council with regard to legal protection insurance, which it defined in Art. 161 OS as follows: "By the legal protection insurance contract, the insurance company undertakes, against payment of a premium, to reimburse the costs incurred by legal matters or to provide services in such matters"¹².

  (61) In this case, when a client enters into a legal subscription contract with Parreaux, Thiébaud & Partners/Justicia SA, he agrees to pay an annual premium which then allows him to have access to a catalogue of services depending on the subscription chosen. Parreaux, Thiébaud & Partners/Justicia SA undertakes for their part to provide legal assistance to the client if necessary, provided that the conditions for taking charge of the case are met. Parreaux, Thiébaud & Partners/Justicia SA leaves itself a wide margin of discretion in deciding whether it is a case of prior art or whether the case has little chance of success. In these cases, the services remain partially covered, up to 50&percnt. This approach is more generous than the practice of legal insurance companies on the market. In fact, cases of prior art are not in principle covered by legal protection insurance and certain areas are also often excluded from the range of services included in the contract.

  (62) The autonomous nature of the transaction: The autonomy of the transaction is essential to the insurance business, even though the nature of an insurance transaction does not disappear simply because it is linked in the same agreement to services of another type. In order to determine whether the insurance service is presented simply as an ancillary agreement or a modality of the entire transaction, the respective importance of the two elements of the contract in the specific case must be taken into account and this must be assessed in the light of the circumstances¹³.

  (63) In this case, the obligation for Parreaux, Thiébaud & Partners/Justicia SA to provide legal services to clients who have subscribed to the subscriptions and to bear administrative costs, respectively lawyers' fees, court fees or expert fees does not represent a commitment that would be incidental or complementary to another existing contract or to another predominant service between Parreaux, Thiébaud & Partners/Justicia SA and the clients. On the contrary, the investigation showed that the legal subscriptions offered are autonomous contracts.

  (64) Risk compensation based on statistical data: Finally, the case law requires, as another characteristic of the insurance business, that the company compensates the risks assumed in accordance with the laws of statistics. The requirements set by the Federal Court for this criterion are not always formulated uniformly in judicial practice. The Federal Court does not require a correct actuarial calculation but rather risk compensation based on statistical data¹⁴. Furthermore, it has specified that it is sufficient for the risk compensation to be carried out according to the law of large numbers and according to planning based on the nature of the business¹⁵. In another judgment¹⁶, the Federal Court adopted a different approach and considered that the criterion of risk compensation based on statistical data is met when the income from the insurance business allows expenses to be covered while leaving a safety margin. Finally, in another judgment¹⁷, the High Court deduced from the fact that the products were offered to an indeterminate circle of people that the risks would be logically distributed among all customers according to the laws of statistics and large numbers¹⁸.

  (65) In this case, the risks assumed by Parreaux, Thiébaud & Partners/Justicia SA are offset by the laws of statistics, at the very least by the compensation of risks according to the law of large numbers. Knowing that only a very small part of their clientele will use the services provided by Parreaux, Thiébaud & Partners/Justicia SA, the latter are counting on the fact that the income from the contributions from legal subscriptions will be used to cover the expenses incurred for clients whose cases must be handled by Parreaux, Thiébaud & Partners/Justicia SA while leaving a safety margin. Indeed, the analysis of the files revealed that when a client reports a case to Parreaux, Thiébaud & Partners/Justicia SA, the costs incurred to handle the case are at least three times higher than the contribution paid. Support in this proportion is only possible by assuming that only a few clients will need legal assistance and by ensuring that all contributions are used to cover these costs. (…).

  (66) (…) The investigation, however, revealed that there is indeed an economic adequacy between the services provided to clients by Parreaux, Thiébaud & Partners / Justicia SA and the subscription fees it collects. In this way, Parreaux, Thiébaud & Partners / Justicia SA offsets its own risks, namely the costs related to the legal services it provides as well as the risk of not obtaining repayment of the loan granted to the client, by the diversification of risks that occurs when a large number of corresponding transactions are concluded, i.e. according to the law of large numbers. In view of the above, there is no doubt that the risk compensation criterion is met within the framework of the business model of Parreaux, Thiébaud & Partners / Justicia SA.

  (69) (…) In view of the above, it is established that Parreaux, Thiébaud & Partners and Justicia SA have exercised, respectively exercise, an insurance activity within the meaning of Art. 2 para. 1 let. a in relation to Art. 3 para. 1 LSA and Art. 161 OS without having the required authorisation from FINMA. Indeed, upon conclusion of a subscription, clients can request legal services from Parreaux, Thiébaud & Partners/Justicia SA against payment of an annual premium. In addition to these services, the latter grant a loan to clients to cover legal costs and lawyers' fees. Although these loans are repayable "according to the agreed terms", none of these terms appear to exist in practice and no loan repayments have been recorded. Finally, the mere fact of bearing the risk of insolvency of clients is sufficient for the insurance risk criterion to be met. Furthermore, in view of the current number of legal subscription contracts held by Justicia SA, the turnover generated by its legal subscriptions and the fact that Justicia SA, and before it Parreaux, Thiébaud & Partners, offers its services to an unlimited number of persons, there are no special circumstances within the meaning of Art. 2 para. 3 LSA allowing Parreaux, Thiébaud & Partners and Justicia SA to be released from supervision under Art. 2 para. 1 LSA.

  (…)

  Dispositif

  ---

  1. Loi fédérale sur la surveillance des entreprises d'assurance (LSA; RS 961.01).
  2. Art. 1 al. 2 LSA.
  3. Art. 2 al. 1 let. a en relation avec l’art. 3 al. 1 LSA.
  4. Art. 2 al. 3 LSA.
  5. Art. 1 al. 1 let. a OS.
  6. HEISS/MÖNNICH, in: Hsu/Stupp (éd.), Basler Kommentar, Versicherungsaufsichtsgesetz, Bâle 2013, nos 5 s ad art. 2 LSA et les références citées.
  7. ATF 114 Ib 244 consid. 4.a et les références citées.
  8. HEISS/MÖNNICH, op. cit., nos 15 ss ad art. 2 LSA et les références citées.
  9. HEISS/MÖNNICH, op. cit., nos 5 s. ad art. 2 LSA et les références citées.
  10. TF 2C_410/2010 du 21 janvier 2011 consid. 3.2 et 4.2.
  11. HEISS/MÖNNICH, op. cit., nos 23 ss ad art. 2 LSA et les références citées.
  12. HEISS/MÖNNICH, op. cit., nos 26 ss ad art. 2 LSA et les références citées.
  13. HEISS/MÖNNICH, op. cit., nos 30ss ad art. 2 LSA et les références citées.
  14. ATF 107 Ib 54 consid. 5.
  15. Ibid.
  16. ATF 92 I 126, consid. 3.
  17. TF 2C_410/2010 du 21 janvier 2010 consid. 3.4.
  18. HEISS/MÖNNICH, op. cit., nos 34 ss ad art. 2 LSA et les références citées.

• The NeuroFedora Blog Next Open NeuroFedora meeting: 10 February 2025 1300 UTC

  

  Photo by William White on Unsplash.

  
  

  Please join us at the next regular Open NeuroFedora team meeting on Monday 10 February 2025 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, February 10, 2025 13:00 UTC'
  

  The meeting will be chaired by @ankursinha. The agenda for the meeting is:

  • New introductions and roll call.
  • Tasks from last meeting.
  • Open Pagure tickets.
  • Package health check.
  • Open package reviews check.
  • CompNeuro lab compose status check for Fedora 41/rawhide.
  • Neuroscience query of the week
  • Next meeting day, and chair.
  • Open floor.

  We hope to see you there!

• Fedora fans اجرای هوش مصنوعی با LM Studio

  

  در دنیای هوش مصنوعی، ابزارهای گوناگونی برای اجرای مدل‌های زبانی بزرگ (LLMs) به‌صورت محلی وجود دارند. یکی از این ابزارها LM Studio است که به کاربران امکان می‌دهد مدل‌های پیشرفته را بدون نیاز به اتصال دائم به اینترنت اجرا کنند. در این مقاله، به معرفی LM Studio، ویژگی‌های کلیدی آن و نحوه نصب این ابزار […]

  The post اجرای هوش مصنوعی با LM Studio first appeared on طرفداران فدورا.

February 09, 2025

• Andreas Schneider Local authentication hub

  by Alexander Bokovoy and Andreas Schneider

  FOSDEM 2025 is just behind us and it was a great event as always. Alexander and I had a chance to talk
  about the local authentication hub project. Our FOSDEM talk was “localkdc – a general local authentication hub”. You can watch it and come back here for more details.

  But before going into details, let us provide a bit of a background. It is 2025 now and we should go almost three decades back (ugh!).

  

  History dive

  Authentication on Linux systems is interwoven with the identity of the users. Once a user logged in, a process is running under a certain POSIX account identity. Many applications validate the presence of the account prior to the authentication itself. For example, the OpenSSH server does check the POSIX account and its properties and if the user was not found, will intentionally corrupt the password passed to the PAM authentication stack request. An authentication request will fail but the attempt will be recorded in the system journal.

  This joint operation between authentication and identification sources in Linux makes it important to maintain a coherent information state. No wonder that in corporate environments it is often handled centrally: user and group identities stored at a central server and sourced from that one by a local software, such as SSSD. In order to consume these POSIX users and groups, SSSD needs to be registered with the centralized authority or, in other words, enrolled into the domain. Domain enrollment allows not only identity and authentication of users: both the central server and the enrolled client machine can mutually authenticate each other and be sure they talk to the right authority when authenticating the user.

  FreeIPA provides a stable mechanism for building a centralized domain management system. Each user account has POSIX attributes associated with it and each user account is represented by the Kerberos principal. Kerberos authentication can be used to transfer the authentication state across multiple services and provides a chance for services to discover user identity information beyond POSIX. It also makes strong linking between the POSIX level identity and authentication structure possible: for example, a Kerberos service may introspect a Kerberos ticket presented by a user’s client application to see how this user was authenticated originally: with a password or some specific passwordless mechanism. Or, perhaps, that a client application performs operations on behalf of the user after claiming it was authenticated using a different (non-Kerberos) authentication.

  Local user accounts’ use lacks this experience. Each individual service needs to reauthenticate a user again and again. Local system login: authenticate. Elevating privileges through SUDO? Authenticate again, if not explicitly configured otherwise. Details of the user session state, like how long this particular session is active, is not checked by the applications, making it also harder to limit access. There is no information on how this user was authenticated. Finally, overall user experience between local (standalone) authentication and domain-enrolled one differs, making it harder to adjust and educate users.

  Local authentication is also typically password-based. This is not a bad thing in itself but depending on applications and protocols, worse choices could be made, security-wise. For example, contemporary SMB 3.11 protocol is quite secure if authenticated using Kerberos. For non-Kerberos usage, however, it is left to rely on NTLM authentication protocol which requires use of RC4 stream cipher. There are multiple attacks known to break RC4-based encryption, yet it is still used in majority of non-domain joined communications using SMB protocol simply because there was no (so far) alternative. To be correct, there was always an alternative, use of Kerberos protocol, but setting it up for individual isolated systems wasn’t practical.

  The Kerberos protocol assumes the use of three different parties: a client, a service, and a key distribution center (KDC). In corporate environments a KDC is part of the domain controller system, a client and a service are both domain members, computers are enrolled in the domain. The client authenticates to KDC and obtains a Kerberos ticket granting ticket (TGT). It then requests a service ticket from the KDC by presenting its TGT and then presents this service ticket to the service. The service application, on its side, is able to decrypt the service ticket presented by the client and authenticate the request.

  In the late 2000s Apple realised that for individual computers a number of user accounts is typically small and a KDC can be run as a service on the individual computer itself. When both the client and server are on the same computer, this works beautifully. The only problem is that when a user needs to authenticate to a different computer’s service, the client cannot reach the KDC hosted on the other computer because it is not exposed to the network directly. Luckily, MIT Kerberos folks already thought about this problem a decade prior to that: in 1997 a first idea was published for a Kerberos extension that allowed to tunnel Kerberos requests over a different application protocol. This specification became later known as “Initial and Pass Through Authentication Using Kerberos V5 and the GSS-API” (IAKerb). An initial implementation for MIT Kerberos was done in 2009/2010 while Apple introduced it in 2007 to enable remote access to your own Mac across the internet. It came in MacOS X 10.5 as a “Back to My Mac” feature and even got specified in RFC 6281, only to be retired from MacOS in 2019.

  Modern days

  In the 2020s Microsoft continued to work on NTLM removal. In 2023 they announced that all Windows systems will have a local KDC as their local authentication source, accessible externally via selected applications through the IAKerb mechanism. By the end of 2024, we have only seen demos published by Microsoft engineers at various events but this is a promising path forward. Presence of the local KDC in Windows raises an interoperability requirement: Linux systems will have to handle access to Windows machines in a standalone environment over SMB protocol. Authentication is currently done with NTLM, it will eventually be removed, thus we need to support the IAKerb protocol extension.

  The NTLM removal for Linux systems requires several changes. First, the Samba server will need to learn how to accept authentication with the IAKerb protocol extension. Then, Samba client code needs to be able to establish a client connection and advertise IAKerb protocol extension. For kernel level access, the SMB filesystem driver needs to learn how to use IAKerb as well, this will also need to be implemented in the user space cifs-utils package. Finally, to be able to use the same feature in a pure Linux environment, we need to be able to deploy Kerberos KDC locally and do it in an easy manner on each machine.

  This is where we had an idea. If we are going to have a local KDC running on each system, maybe we should use it to handle all authentication and not just for the NTLM removal? This way we can make both the local and domain-enrolled user experience the same and provide access locally to a whole set of authentication methods we support for FreeIPA: passwords, smartcards, one-time passwords and remote RADIUS server authentication, use of FIDO2 tokens, and authentication against an external OAuth2 Identity Provider using a device authorization grant flow.

  How “local” a local KDC should be?

  On standalone systems it is often not desirable to run daemons continuously. Also, it is not desirable to expose these services to the connected network if they really don’t need to be exposed. A common approach to solve this problem is by providing a local inter-process communication (IPC) mechanism to communicate with the server components. We chose to expose a local KDC via UNIX domain sockets. A UNIX domain socket is a well-known mechanism and has known security properties. With the help of a systemd feature called socket activation, we also can start local KDC on demand, when a Kerberos client connects over the UNIX domain socket. Since on local systems actual authentication requests don’t happen often, this helps to reduce memory and CPU usage in the long run.

  If a local KDC is only accessible over a UNIX domain socket, remote applications could not get access to it directly. This means they would need to have help from a server application that can utilize the IAKerb mechanism to pass-through the communication between a client and the KDC. It would enable us to authenticate as a local user remotely from a different machine. Due to how the IAKerb mechanism is designed and integrated into GSS-API, this only allows password-based authentication. Anything that requires passwordless methods cannot obtain initial Kerberos authentication over IAKerb, at least at this point.

  Here is a small demo on Fedora, using our localkdc tool to start a local KDC, obtain a Kerberos ticket upon login. The tickets can then be used effortlessly to authenticate to local services such as SUDO or Samba. For remote access we rely on Samba support for IAKerb and authenticate with GSSAPI but local smbclient uses a password first to obtain the initial ticket over IAKerb. This is purely a limitation of the current patches we have to Samba.

  Watch the localkdc demo

  Make a pause here and think about the implications. We have an initial Kerberos ticket from the local system. The Kerberos ticket embeds details of how this authentication happened. We might have used a password to authenticate, or a smartcard. Or any other supported pre-authentication methods. We could reuse the same methods FreeIPA already provides in the centralized environment.

  The Kerberos ticket also can contain details about the user session, including current group membership. It does not current have that in the local KDC case but we aim to fix that. This ticket can be used to authenticate to any GSS-API or Kerberos-aware service on this machine. If a remote machine accepts Kerberos, it theoretically could accept a ticket presented by a client application running on the local machine as well. Only, to do that it needs to be able to communicate with our local KDC and it couldn’t access it.

  Trust management

  Luckily, a local KDC deployment is a full-featured Kerberos realm and thus can establish cross-realm agreements with other Kerberos realms. If two “local” KDC realms have trust agreements between each other, they can issue cross-realm Kerberos tickets which applications can present over IAKerb to the remote “local” KDC. Then a Kerberos ticket to a service running on the target system can be requested and issued by the system’s local KDC.

  Thus, we can achieve passwordless authentication locally on Linux systems and have the ability to establish peer to peer agreements across multiple systems, to allow authentication requests to flow and operate on commonly agreed credentials. A problem now moves to the management area: how to manage these peer to peer agreements and permissions in an easy way?

  Systemd User/Group API support

  MIT Kerberos KDC implementation provides a flexible way to handle Kerberos principals’ information. A database backend (KDB) implementation can be dynamically loaded and replaced. This is already used by both FreeIPA and Samba AD to integrate MIT Kerberos KDC with their own database backends based on different LDAP server implementations. For a local KDC use case running a full-featured LDAP server is not required nor intended. However, it would be great if different applications could expose parts of the data needed by the KDB interfaces and cooperate together. Then a single KDB driver implementation could be used to streamline and provide uniform implementation of Kerberos-specific details in a local KDC.

  One of the promising interfaces to achieve that is the User/Group record lookup API via varlink from systemd. Varlink allows applications to register themselves and listen on UNIX domain sockets for communication similar to D-Bus but with much less implementation overhead. The User/Group API technically also allows to merge data coming from different sources when an application inquires the information. “Technically”, because io.systemd.Multiplexer API endpoint currently does not support merging non-overlapping data representing the same account from multiple sources. Once it would become possible, we could combine the data dynamically and may interact with users on demand when corresponding requsts come in. Or we can implement our own blending service.

  Blending data requests from multiple sources within MIT KDC needs a specialized KDB driver. We certainly don’t want this driver to duplicate the code from other drivers, so making these drivers stackable would be a good option. Support for one level of stacking has been merged to MIT Kerberos through a quickly processed pull request and will be available in the next MIT Kerberos release. This allows us to have a single KDB driver that loads other drivers specialized in storing Kerberos principals and processing additional information like MS-PAC structure or applying additional authorization details.

  Establishing trusts

  If Alice and Bob are in the same network and want to exchange some files, they could do this using SMB and Samba. But that Alice can authenticate on Bob’s machine, they would need to establish a Kerberos cross realm trust. With the current tooling this is a complex task. For users we need to make this more accessible. We want to allow users to request trust on demand and validate these requests interactively. We also want to allow trust to be present for a limited timeframe, automatically expiring or manually removed.

  If we have a Kerberos principal lookup on demand through a curated varlink API endpoint, we also can have a user-facing service to initiate establishing the trust between two machines on demand. Imagine a user trying to access SMB share on one desktop system that triggers a pop-up to establish trust relationship with a corresponding local KDC on the remote desktop system. Both owners of the systems would be able to communicate out of band that provided information is correct and can be trusted. Once it is done, we can return back the details of the specific Kerberos principal that represents this trust relationship. We can limit lifetime of this agreement so that it would disappear automatically in one hour or a day, or a week.

  Current state of local authentication hub

  We started with two individual implementation paths early in 2024:

  • Support IAKerb in MIT Kerberos and Samba
  • Enable MIT Kerberos to be used locally without network exposure

  MIT Kerberos did have support for IAKerb protocol extension for more than a decade but since Microsoft introduced some changes to the protocol, those changes needed to be integrated as well. This was completed during summer 2024, though no upstream release is available yet. MIT Kerberos typically releases new versions yearly in January so we hope to get some updates early 2025.

  Samba integration with IAKerb is currently under implementation. Originally, Microsoft was planning to release Windows 11 and Windows Server 2025 with IAKerb support enabled during autumn 2024. However, the Windows engineering team faced some issues and IAKerb is still not enabled in the Windows Server 2025 and Windows 11 releases. We are looking forward to getting access to Windows builds that enable IAKerb support to ensure interoperability before merging Samba changes upstream. We also need to complete the Samba implementation to properly support locally-issued Kerberos tickets and not only do acquisition of the ticket based on the password.

  Meanwhile, our cooperation with MIT Kerberos development team led to advancements in the local KDC support. The MIT Kerberos KDC can now be run over a UNIX domain socket. Also on systemd-enabled systems we allow socket activation, transforming local KDC into an on-demand service. We will continue our work on a dynamic database for a local KDC, to allow on-demand combination of resources from multiple authoritative local sources (Samba, FreeIPA, SSSD, local KDC, future dynamic trust application).

  For experiments and ease of deployments, a new configuration tool was developed, localkdc. The tool is available at localkdc and COPR repository can be used to try the whole solution on Fedora.

  If you want to get that test tried in a simple setup, you might be interested in a tool that we developed initially for FreeIPA: FreeIPA local tests. This tool allows to provision and run a complex test environment in podman containers. The video of the local KDC usage was actually generated automatically by the scripts from here.

• Alexander Bokovoy Local authentication hub

  FOSDEM 2025 is just behind us and it was a great event. I had a chance to talk about the local authentication hub project. The talk was well received and I got a lot of questions about the project. We ran Identity and Access Management devroom for the second time in row and it was a great success. I had two talks at the IAM devroom, both were process reports on the activity we have announced at FOSDEM 2024. Now that both recordings of the both talks published, I can share articles which go into more details.

  Local authentication hub

  Our FOSDEM talk is “localkdc - a general local authentication hub”. You can watch it and come back here for more details.

  But before going into details, let me provide a bit of a background. It is 2025 now and we should go almost three decades back (ugh!).

  History dive

  Authentication on Linux systems is interwoven with the identity of the users. Once a user logged in, a process is running under a certain POSIX account identity. Many applications validate the presence of the account prior to the authentication itself. For example, the OpenSSH server does check the POSIX account and its properties and if the user was not found, will intentionally corrupt the password passed to the PAM authentication stack request. An authentication request will fail but the attempt will be recorded in the system journal.

  This joint operation between authentication and identification sources in Linux makes it important to maintain a coherent information state. No wonder that in corporate environments it is often handled centrally: user and group identities stored at a central server and sourced from that one by a local software, such as SSSD. In order to consume these POSIX users and groups, SSSD needs to be registered with the centralized authority or, in other words, enrolled into the domain. Domain enrollment allows not only identity and authentication of users: both the central server and the enrolled client machine can mutually authenticate each other and be sure they talk to the right authority when authenticating the user.

  FreeIPA provides a stable mechanism for building a centralized domain management system. Each user account has POSIX attributes associated with it and each user account is represented by the Kerberos principal. Kerberos authentication can be used to transfer the authentication state across multiple services and provides a chance for services to discover user identity information beyond POSIX. It also makes strong linking between the POSIX level identity and authentication structure possible: for example, a Kerberos service may introspect a Kerberos ticket presented by a user’s client application to see how this user was authenticated originally: with a password or some specific passwordless mechanism. Or, perhaps, that a client application performs operations on behalf of the user after claiming it was authenticated using a different (non-Kerberos) authentication.

  Local user accounts’ use lacks this experience. Each individual service needs to reauthenticate a user again and again. Local system login: authenticate. Elevating privileges through SUDO? Authenticate again, if not explicitly configured otherwise. Details of the user session state, like how long this particular session is active, is not checked by the applications, making it also harder to limit access. There is no information on how this user was authenticated. Finally, overall user experience between local (standalone) authentication and domain-enrolled one differs, making it harder to adjust and educate users.

  Local authentication is also typically password-based. This is not a bad thing in itself but depending on applications and protocols, worse choices could be made, security-wise. For example, contemporary SMB 3.11 protocol is quite secure if authenticated using Kerberos. For non-Kerberos usage, however, it is left to rely on NTLM authentication protocol which requires use of RC4 stream cipher. There are multiple attacks known to break RC4-based encryption, yet it is still used in majority of non-domain joined communications using SMB protocol simply because there was no (so far) alternative. To be correct, there was always an alternative, use of Kerberos protocol, but setting it up for individual isolated systems wasn’t practical.

  The Kerberos protocol assumes the use of three different parties: a client, a service, and a key distribution center (KDC). In corporate environments a KDC is part of the domain controller system, a client and a service are both domain members, computers are enrolled in the domain. The client authenticates to KDC and obtains a Kerberos ticket granting ticket (TGT). It then requests a service ticket from the KDC by presenting its TGT and then presents this service ticket to the service. The service application, on its side, is able to decrypt the service ticket presented by the client and authenticate the request.

  In the late 2000s Apple realised that for individual computers a number of user accounts is typically small and a KDC can be run as a service on the individual computer itself. When both the client and server are on the same computer, this works beautifully. The only problem is that when a user needs to authenticate to a different computer’s service, the client cannot reach the KDC hosted on the other computer because it is not exposed to the network directly. Luckily, MIT Kerberos folks already thought about this problem a decade prior to that: in 1997 a first idea was published for a Kerberos extension that allowed to tunnel Kerberos requests over a different application protocol. This specification became later known as “Initial and Pass Through Authentication Using Kerberos V5 and the GSS-API” (IAKerb). An initial implementation for MIT Kerberos was done in 2009/2010 while Apple introduced it in 2007 to enable remote access to your own Mac across the internet. It came in MacOS X 10.5 as a “Back to My Mac” feature and even got specified in RFC 6281, only to be retired from MacOS in 2019.

  Modern days

  In the 2020s Microsoft continued to work on NTLM removal. In 2023 they announced that all Windows systems will have a local KDC as their local authentication source, accessible externally via selected applications through the IAKerb mechanism. By the end of 2024, we have only seen demos published by Microsoft engineers at various events but this is a promising path forward. Presence of the local KDC in Windows raises an interoperability requirement: Linux systems will have to handle access to Windows machines in a standalone environment over SMB protocol. Authentication is currently done with NTLM, it will eventually be removed, thus we need to support the IAKerb protocol extension.

  The NTLM removal for Linux systems requires several changes. First, the Samba server will need to learn how to accept authentication with the IAKerb protocol extension. Then, Samba client code needs to be able to establish a client connection and advertise IAKerb protocol extension. For kernel level access, the SMB filesystem driver needs to learn how to use IAKerb as well, this will also need to be implemented in the user space cifs-utils package. Finally, to be able to use the same feature in a pure Linux environment, we need to be able to deploy Kerberos KDC locally and do it in an easy manner on each machine.

  This is where we had an idea. If we are going to have a local KDC running on each system, maybe we should use it to handle all authentication and not just for the NTLM removal? This way we can make both the local and domain-enrolled user experience the same and provide access locally to a whole set of authentication methods we support for FreeIPA: passwords, smartcards, one-time passwords and remote RADIUS server authentication, use of FIDO2 tokens, and authentication against an external OAuth2 Identity Provider using a device authorization grant flow.

  How “local” a local KDC should be?

  On standalone systems it is often not desirable to run daemons continuously. Also, it is not desirable to expose these services to the connected network if they really don’t need to be exposed. A common approach to solve this problem is by providing a local inter-process communication (IPC) mechanism to communicate with the server components. We chose to expose a local KDC via UNIX domain sockets. A UNIX domain socket is a well-known mechanism and has known security properties. With the help of a systemd feature called socket activation, we also can start local KDC on demand, when a Kerberos client connects over the UNIX domain socket. Since on local systems actual authentication requests don’t happen often, this helps to reduce memory and CPU usage in the long run.

  If a local KDC is only accessible over a UNIX domain socket, remote applications could not get access to it directly. This means they would need to have help from a server application that can utilize the IAKerb mechanism to pass-through the communication between a client and the KDC. It would enable us to authenticate as a local user remotely from a different machine. Due to how the IAKerb mechanism is designed and integrated into GSS-API, this only allows password-based authentication. Anything that requires passwordless methods cannot obtain initial Kerberos authentication over IAKerb, at least at this point.

  Here is a small demo on Fedora, using our localkdc tool to start a local KDC, obtain a Kerberos ticket upon login. The tickets can then be used effortlessly to authenticate to local services such as SUDO or Samba. For remote access we rely on Samba support for IAKerb and authenticate with GSSAPI but local smbclient uses a password first to obtain the initial ticket over IAKerb. This is purely a limitation of the current patches we have to Samba.

  Make a pause here and think about the implications. We have an initial Kerberos ticket from the local system. The Kerberos ticket embeds details of how this authentication happened. We might have used a password to authenticate, or a smartcard. Or any other supported pre-authentication methods. We could reuse the same methods FreeIPA already provides in the centralized environment.

  The Kerberos ticket also can contain details about the user session, including current group membership. It does not current have that in the local KDC case but we aim to fix that. This ticket can be used to authenticate to any GSS-API or Kerberos-aware service on this machine. If a remote machine accepts Kerberos, it theoretically could accept a ticket presented by a client application running on the local machine as well. Only, to do that it needs to be able to communicate with our local KDC and it couldn’t access it.

  Trust management

  Luckily, a local KDC deployment is a full-featured Kerberos realm and thus can establish cross-realm agreements with other Kerberos realms. If two “local” KDC realms have trust agreements between each other, they can issue cross-realm Kerberos tickets which applications can present over IAKerb to the remote “local” KDC. Then a Kerberos ticket to a service running on the target system can be requested and issued by the system’s local KDC.

  Thus, we can achieve passwordless authentication locally on Linux systems and have the ability to establish peer to peer agreements across multiple systems, to allow authentication requests to flow and operate on commonly agreed credentials. A problem now moves to the management area: how to manage these peer to peer agreements and permissions in an easy way?

  Systemd User/Group API support

  MIT Kerberos KDC implementation provides a flexible way to handle Kerberos principals’ information. A database backend (KDB) implementation can be dynamically loaded and replaced. This is already used by both FreeIPA and Samba AD to integrate MIT Kerberos KDC with their own database backends based on different LDAP server implementations. For a local KDC use case running a full-featured LDAP server is not required nor intended. However, it would be great if different applications could expose parts of the data needed by the KDB interfaces and cooperate together. Then a single KDB driver implementation could be used to streamline and provide uniform implementation of Kerberos-specific details in a local KDC.

  One of the promising interfaces to achieve that is the User/Group record lookup API via varlink from systemd. Varlink allows applications to register themselves and listen on UNIX domain sockets for communication similar to D-Bus but with much less implementation overhead. The User/Group API technically also allows to merge data coming from different sources when an application inquires the information. “Technically”, because io.systemd.Multiplexer API endpoint currently does not support merging non-overlapping data representing the same account from multiple sources. Once it would become possible, we could combine the data dynamically and may interact with users on demand when corresponding requsts come in. Or we can implement our own blending service.

  Blending data requests from multiple sources within MIT KDC needs a specialized KDB driver. We certainly don’t want this driver to duplicate the code from other drivers, so making these drivers stackable would be a good option. Support for one level of stacking has been merged to MIT Kerberos through a quickly processed pull request and will be available in the next MIT Kerberos release. This allows us to have a single KDB driver that loads other drivers specialized in storing Kerberos principals and processing additional information like MS-PAC structure or applying additional authorization details.

  Establishing trusts

  If Alice and Bob are in the same network and want to exchange some files, they could do this using SMB and Samba. But that Alice can authenticate on Bob’s machine, they would need to establish a Kerberos cross realm trust. With the current tooling this is a complex task. For users we need to make this more accessible. We want to allow users to request trust on demand and validate these requests interactively. We also want to allow trust to be present for a limited timeframe, automatically expiring or manually removed.

  If we have a Kerberos principal lookup on demand through a curated varlink API endpoint, we also can have a user-facing service to initiate establishing the trust between two machines on demand. Imagine a user trying to access SMB share on one desktop system that triggers a pop-up to establish trust relationship with a corresponding local KDC on the remote desktop system. Both owners of the systems would be able to communicate out of band that provided information is correct and can be trusted. Once it is done, we can return back the details of the specific Kerberos principal that represents this trust relationship. We can limit lifetime of this agreement so that it would disappear automatically in one hour or a day, or a week.

  Current state of local authentication hub

  We started with two individual implementation paths early in 2024:

  • support IAKerb in MIT Kerberos and Samba
  • enable MIT Kerberos to be used locally without network exposure

  MIT Kerberos did have support for IAKerb protocol extension for more than a decade but since Microsoft introduced some changes to the protocol, those changes needed to be integrated as well. This was completed during summer 2024, though no upstream release is available yet. MIT Kerberos typically releases new versions yearly in January so we hope to get some updates early 2025.

  Samba integration with IAKerb is currently under implementation. Originally, Microsoft was planning to release Windows 11 and Windows Server 2025 with IAKerb support enabled during autumn 2024. However, the Windows engineering team faced some issues and IAKerb is still not enabled in the Windows Server 2025 and Windows 11 releases. We are looking forward to getting access to Windows builds that enable IAKerb support to ensure interoperability before merging Samba changes upstream. We also need to complete the Samba implementation to properly support locally-issued Kerberos tickets and not only do acquisition of the ticket based on the password.

  Meanwhile, our cooperation with MIT Kerberos development team led to advancements in the local KDC support. The MIT Kerberos KDC can now be run over a UNIX domain socket. Also on systemd-enabled systems we allow socket activation, transforming local KDC into an on-demand service. We will continue our work on a dynamic database for a local KDC, to allow on-demand combination of resources from multiple authoritative local sources (Samba, FreeIPA, SSSD, local KDC, future dynamic trust application).

  For experiments and ease of deployments, a new configuration tool was developed, localkdc. The tool is available at localkdc and COPR repository can be used to try the whole solution on Fedora.

  If you want to get that test tried in a simple setup, you might be interested in a tool that we developed initially for FreeIPA: FreeIPA local tests. This tool allows to provision and run a complex test environment in podman containers. The video of the local KDC usage was actually generated automatically by the scripts from https://github.com/abbra/freeipa-local-tests/tree/main/ipalab-config/localkdc.

February 08, 2025

• Kevin Fenzi Bits from early February 2025

  

  Lets keep the blogging rolling. This week went by really fast, but a lot of it for me was answering emails and pull requests and meetings. Those are all important, but sometimes it makes it seem like not much was actually accomplished in the week.

  riscv secondary koji hub

  I got some x86 buildvm's setup. These are to do tasks that don't need to be done on a riscv builder, like createrepo/newrepos or the like. I'm still having a issue with auth on them however, which is related to the auth issue with the web interface. Will need to get that sorted out next week.

  f42 branching day

  Tuesday was the f42 branching day. It went pretty smoothly this cycle I think, but there's always a small number of things to sort out. It's really the most complex part of the release cycle for releng. So many moving parts and dispirate repos and configs needing changing. This time I tried to stay out of actually doing anything, in favor of just providing info or review for Samyak who was doing all the work. I mostly managed to do that.

  Datacenter move

  Planning for the datacenter move is moving along. I've been working on internal documents around the stuff that will be shipped after we move, and next week I am hoping to start a detailed plan for the logical migration itself. It's a pretty short timeline, but I am hoping it will all go smoothly in the end. We definitely will be in a better place with better hardware once we are done, so I am looking forward to that.

  comments? additions? reactions?

  As always, comment on mastodon: https://fosstodon.org/@nirik/113969409712070764

• William Moreno Reyes Notas sobre usar la Nube de Oracle.

   

  La nube de Oracle, si bien no tan conocida como la nube Amazon, es una opción interesante para aquellos que requieran un proveedor de servicios en la nube, tiene una oferta de servicios menos extensa, pero seamos sinceros: quien usa todos los recursos que ofrece AWS?

  Una gran ventaja del servicio de Oracle es que te permite crear un par de maquinas virtuales de pocos recursos de forma gratuita, de los cuales pueden ser dos pequeñas maquinas virtuales x86_64 o gasta 4 maquinas virtuales con arquitectura ARM.
  

  
  

  Puedes crear fácilmente una nueva instancia de maquina virtual:

  

  
  

  Lamentablemente Fedora no esta disponible en la nube de Oracle pero si Oracle Linux, Rocky Linux y Alma Linux:

  

  
   En la nube de Oracle es necesario acceder con una llave segura para SSH:

  

  
   El usuario para acceder a la nube de Oracle es opc:

   ssh -i ssh-key-####-##-##.key opc@###.##.###.###

  Al intentar acceder la primera vez obtuve el mensaje de error:
  

  Permissions 0644 for 'ssh-key-#########.key' are too open.

   No había encontrado este error anteriormente, la solución es hacer el archivo solo disponible para el usuario actual con:

  chmod 600 ssh-key-#########.key

  Una vez ingresado al servidor no se requiere contraseña para pasar a una consola de administrador con:

  sudo bash

  Una vez con acceso al terminal las tareas principales son:

  Actualizar el sistema:

  dnf update -y

  Yo prefiero utilizar cockpit que se puede instalar con:

  dnf install -y cockpit
  

  systemctl enable --now  cockpit.socket

   sudo firewall-cmd --add-service=cockpit
  sudo firewall-cmd --add-service=cockpit --permanent

  
  

   

February 07, 2025

• Fedora Community Blog Infra and RelEng Update – Week 6

  This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. 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: 03 – 07 February 2025

  

  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:
    • Update redirect URIs
    • [CommOps] Open Data Hub on Communishift
    • retire easyfix
    • bvmhost-p09-03 ends in emergency mode
    • Add StartInstanceRefresh permission for fedora-ci-testing-farm user in AWS
    • Deploy Element Server Suite operator in staging
    • Create CentOS calendar
    • Pagure returns error 500 trying to open a PR on https://src.fedoraproject.org/rpms/python-setuptools-gettext
    • a real domain name for konflux
    • Retirement of `monitor-dashboard` tracker
    • Create a POC integration in Konflux for fedora-infra/webhook-to-fedora-messaging
    • Retirement of `monitor-gating` tracker
    • maubot-meetings bot multi line paste is cut
    • setup ipa02.stg and ipa03.stg again as replicas
    • Manage our new testing.farm domain via AWS Route53
    • Add support for creating RDS instances under `testing-farm-` prefix
    • Move OpenShift apps from deploymentconfig to deployment
    • The process to update the OpenH264 repos is broken
    • httpd 2.4.61 causing issue in fedora infrastructure
    • Support allocation dedicated hosts for Testing Farm
    • EPEL minor version archive repos in MirrorManager
    • vmhost-x86-copr01.rdu-cc.fedoraproject.org DOWN
    • Add yselkowitz to list to notify when ELN builds fail
    • Cleaning script for communishift
    • rhel7 eol
    • move resultsdb-ci-listener deployment pipeline
    • rhel7 EOL – github2fedmsg
    • Move from iptables to firewalld
    • Help me move my discourse bots to production?
    • fedmsg -> fedora-messaging migration tracker
    • rhel9 adoption
    • Create monitoring tool for rabbitmq certificates
    • Replace Nagios with Zabbix in Fedora Infrastructure
    • Migration of registry.fedoraproject.org to quay.io
    • Commits don’t end up on the scm-commits list
  • Done:
    • Deactivating Fedora Account
    • flatpak-indexer may have stalled
    • Access to RISC-V dedicated public area
    • Planned Outage – updates / reboots – 2025-01-29 21:00UTC
    • fedorapeople.org directory listing theme needs refreshing

  CentOS Infra including CentOS CI

  • In progress:
    • Setup hyperscale 10 image build tags
    • [spike] : investigating options/alternatives for the upcoming DC move
    • Zuul CI namespace
    • Testing Jenkins – c10s x86_64 metal doesn’t provision
    • Release Improvements
  • Done:
    • Adapt zabbix-agent ansible role for new hardware raid controller

  Release Engineering

  • In progress:
    • rpms/sssd – The permissions on this repository are being updated.
    • Please untag tinysparql-3.8~rc-3.fc42
    • please remove unwanted rpmdevtools commit accidentally pushed to rawhide branch
    • 300+ F42FTBFS bugzillas block the F41FTBFS tracker
    • Fedora 42 Mass Rebuild Tracker
    • Quay.io repository for fedora-bootc-tier-x
    • Missing rawhide branch for recently created package ‘pybind11-json’
    • F42 Self-Contained Change: Switch to EROFS for Live Media
    • Please remove two branches from octave-iso2mesh
    • Send compose reports to a to-be-created separate ML
    • .sqlite metadata missing in f41-updates and f41-updates-testing repositories
    • F42 system-wide change: GNU Toolchain update for F42 https://fedoraproject.org/wiki/Changes/GNUToolchainF42
    • Delete “firefox-fix” branch in xdg-desktop-portal
    • please create epel10 based el10-openjdk tag
    • Could we have fedoraproject-updates-archive.fedoraproject.org for Rawhide?
    • Investigate and untag packages that failed gating but were merged in via mass rebuild
    • a few mass rebuild bumps failed to git push – script should retry or error
    • Renaming distribution media for Fedora Server
    • Package retirements are broken in rawhide
    • Implement checks on package retirements
    • Untag containers-common-0.57.1-6.fc40
    • orphan-all-packages.py should remove bugzilla_contact entries from fedora-scm-requests as well
    • Packages that fail to build SRPM are not reported during the mass rebuild bugzillas
    • When orphaning packages, keep the original owner as co-maintainer
    • Create an ansible playbook to do the mass-branching
    • RFE: Integration of Anitya to Packager Workflow
    • Cleaning old stuff from koji composes directories
    • Fix tokens for ftbfs_weekly_reminder. script
    • Update bootloader components assignee to “Bootloader Engineering Team”for Improved collaboration
  • Done:
    • urgent – please unretire copy-jdk-configs – buildroot broken
    • tcl-8.6.14-5.fc41 build cannot be added to the bodhi update
    • Unretire hyprcursor
    • Unretire php-phpseclib
    • Updating flatpak-module-tools to 1.1
    • Unretire tachyon
    • Unretire ethos
    • Update ejected from the push because of missing tags
    • Anaconda & bodhi update improvements
    • glibc-headers-2.29-12.fc30 i686 erroneously in x86_64 GA repo
    • Fedora-34-Beta .composeinfo file
    • Add procedure for updating comps to branch process
    • Ensure greenwave bodhiupdate_bodhipush_openqa_upgrade policy is updated when a release goes EOL

  If you have any questions or feedback, please respond to this report or contact us on #redhat-cpe channel on matrix.

  The post Infra and RelEng Update – Week 6 appeared first on Fedora Community Blog.

• Tomas Tomecek Lessons learned from running the Log Detective service

  Log Detective service is live for more than two weeks now. Running an LLM inference server in production is a challenge.

  We started with llama-cpp-python’s server initialy but switched over to llama-cpp server because of its parallel execution feature. I still need to benchmark it to see how much speedup we are getting.

  

  This blog post highlights a few common challenges you might face when operating an inference server.

• Remi Collet 💎 PHPUnit 12

  RPMs of PHPUnit version 12 are available in the remi repository for Fedora ≥ 40 and Enterprise Linux (CentOS, RHEL, Alma, Rocky...).

  Documentation :

  • Documentation for PHPUnit
  • Release Announcement for version 12 of PHPUnit
  • Changes in PHPUnit 12.0

  ℹ️ This new major version requires PHP ≥ 8.3 and is not backward compatible with previous versions, so the package is designed to be installed beside versions 8, 9, 10 and 11.

  Installation:

  dnf --enablerepo=remi install phpunit12

  Notice: This tool is an essential component of PHP QA in Fedora. This version should be available soon in the Fedora ≥ 41 official repository (19 new packages).

  

February 06, 2025

• Dan Horák Firefox 128.7.0 ESR built for ppc64le

  The JIT-enabled Firefox 128.7.0 ESR has been built for Fedora/ppc64le in my Talos COPR repository. The corresponding sources are in my fork of the official Fedora Firefox package and the JIT is coming from Cameron's work.
  
  Currently only Fedora 40 and 41 builds exist, because the build fails for Fedora 42 (and Rawhide) due to the changes in the buildroot - new GCC 15 and other updates. Hopefully I will be able to provide some updates soon, but I haven't dug into it fully yet.

• Harish Pillay 9v1hp GNOME Tip – changing the size of the mouse pointer

  

  

  So, one of the things I’ve wanted to have when doing presentations in person or online is for the mouse pointer of my GNOME desktop to be large enough that it is obvious. My current system running Fedora Linux 41 which comes with GNOME 47 does not have a GUI button to change the size of the mouse pointer.

  Well, here’s the trivial way to do that in the terminal and all’s well.

  First, know what the size of the current mouse pointer is via:

  % gsettings get org.gnome.desktop.interface cursor-size

  That will return the current size, which on my system is 24.

  Then, you can run the following:

  % gsettings set org.gnome.desktop.interface cursor-size 80

  The line above sets the size to 80.

  Go ahead and experiment with different sizes to suit your needs. For me, 80 works just fine. And once my presentation/conf call is over, I reset it to 24.

• Dan Horák kernel 6.14-rc1 available, but panics on PowerNV

  After some struggles to get the kernel building with the latest GCC 15 compiler introduced ~3 weeks ago in Rawhide, we have a -rcX kernel available again in the RawhideNoDebug repo. Unfortunately there is a bug in the cpufreq subsystem causing the 6.14-rc1 kernel to panic on a PowerNV systems like our Power9 Taloses. See my report on the linuxppc mailing list here. Fortunately a fix was posted and queued for a next rc yesterday. I am going to build 6.14-rc1 with the fix applied and will update this post with a link to the resulting rpms.
  
  6.14-rc1 kernel rpms with the fix are here

February 05, 2025

• Kiwi TCMS Kiwi TCMS 14.0

  We're happy to announce Kiwi TCMS version 14.0!

  IMPORTANT:

  This is a major version release which includes security related updates, backwards incompatible changes, several improvements and new translations.

  Recommended upgrade path:

  13.7 -> 14.0
  

  You can explore everything at https://public.tenant.kiwitcms.org!

  ---

  Upstream container images (x86_64):

  kiwitcms/kiwi   latest  a4c45db53541    681MB
  

  IMPORTANT: version tagged and multi-arch container images are available only to subscribers!

  Changes since Kiwi TCMS 13.7

  Security

  • Update node_modules/cross-spawn from 7.0.3 to 7.0.6 to resolve a regular expression denial of service (ReDoS) vulnerability, CVE-2024-21538
  • Update node_modules/semver from 6.3.0 to 6.3.1 to resolve a regular expression denial of service (ReDoS) vulnerability, CVE-2022-25883
  • Note that these are indirect dependencies of Kiwi TCMS, in particular pulled in via some of our developer tools, eslint and webpack, and the risk to existing Kiwi TCMS installations is minimal if at all!

  Improvements

  • Update Django from 5.0.10 to 5.1.6
  • Update django-colorfield from 0.11.0 to 0.12.0
  • Update django-modern-rpc from 1.0.3 to 1.1.0
  • Update django-simple-captcha from 0.6.0 to 0.6.1
  • Update django-simple-history from 3.7.0 to 3.8.0
  • Update mysqlclient from 2.2.6 to 2.2.7
  • Update psycopg[binary] from 3.2.3 to 3.2.4
  • Update pygments from 2.18.0 to 2.19.1
  • Update python-gitlab from 5.1.0 to 5.6.0
  • Update tzdata from 2024.2 to 2025.1
  • Update Node.js runtime from v16 to v22
  • Update node_modules/pdfmake from 0.2.15 to 0.2.18
  • Add Scarf.sh pixel - open source analytics

  Database

  • WARNING: Postgres 12 is no longer supported. Minimum version is 13!
  • Remove index_together from historical migrations

  Settings

  • WARNING: the DEFAULT_FILE_STORAGE and STATICFILES_STORAGE settings have been removed!
  • Explicitly define the STORAGES setting

  Refactoring and testing

  • Update black from 24.10.0 to 25.1.0
  • Update isort from 5.13.2 to 6.0.0
  • Update node_modules/webpack from 5.97.0 to 5.97.1
  • Update node_modules/webpack-cli from 5.1.4 to 6.0.1
  • Refactor request_contents_processor() to expose only data we use which sometimes lead to traceback recursion when rendering templates!
  • Similate an API write performance test with Locust. References Issue #721
  • Simulate a web performance test with Locust + Playwright. References Issue #721. Execution frequencies are informed by our Plausible.io stats

  Translations

  • Updated Chinese Simplified translation
  • Updated Hungarian translation

  Kiwi TCMS Enterprise v14.0-mt

  • Based on Kiwi TCMS v14.0
  • Remove dependency on dict-hash package
  • Update certbot-* from 3.0.1 to 3.1.0
  • Update django-ses from 4.3.0 to 4.4.0
  • Update sentry-sdk from 2.19.0 to 2.20.0
  • Update kiwitcms-tenants from 3.2.1 to 4.0.0
  • Replace deprecated STATICFILES_STORAGE setting

  Private container images

  quay.io/kiwitcms/version            14.0 (aarch64)          9aaf5f3e5c7e    05 Feb 2025     695MB
  quay.io/kiwitcms/version            14.0 (x86_64)           0152d6ac4cec    05 Feb 2025     681MB
  quay.io/kiwitcms/enterprise         14.0-mt (aarch64)       f28044190b68    05 Feb 2025     1.08GB
  quay.io/kiwitcms/enterprise         14.0-mt (x86_64)        317f8f14a984    05 Feb 2025     1.06GB
  

  IMPORTANT: version tagged, multi-arch and Enterprise container images are available only to subscribers!

  How to upgrade

  Backup first! Then follow the Upgrading instructions from our documentation.

  Happy testing!

  ---

  If you like what we're doing and how Kiwi TCMS supports various communities please help us grow!

  • Give â­� on GitHub;
  • Give ğŸ‘� on GitLab;
  • Join our newsletter and follow all project news;
  • Become a contributor and an awesome open source hacker;
  • Become a subscriber and help us sustain development

• David López Surpriselib: Una Herramienta Poderosa para Sistemas de Recomendación

  En el mundo del machine learning, los sistemas de recomendación han ganado una importancia significativa debido a su capacidad para personalizar la experiencia del usuario en diversas plataformas, desde servicios de streaming como Netflix y Spotify hasta comercios electrónicos como Amazon. Estos sistemas utilizan algoritmos complejos para predecir las preferencias de los usuarios y recomendar productos o contenidos que puedan ser de su interés. En este contexto, la librería Surprise en Python emerge como una herramienta especializada para la implementación y evaluación de sistemas de recomendación.

  ¿Qué es la Librería Surprise?

  Surprise (Simple Python Recommendation System Engine) es una librería de Python diseñada específicamente para la construcción y evaluación de sistemas de recomendación. Desarrollada por Nicolas Hug, Surprise se centra en la implementación de algoritmos de filtrado colaborativo, que son una de las técnicas más populares en el ámbito de los sistemas de recomendación. El filtrado colaborativo se basa en la idea de que los usuarios que han tenido gustos similares en el pasado probablemente tendrán gustos similares en el futuro.

  Surprise es una librería ligera y fácil de usar, pero a la vez potente, ya que ofrece una amplia gama de algoritmos de recomendación, herramientas para la evaluación de modelos y utilidades para la manipulación de datos. Además, está construida sobre las bases de NumPy y SciPy, lo que la hace eficiente y compatible con otras librerías de machine learning en Python.

  

  ¿Donde podemos aplicarlo?

  La librería Surprise es ampliamente utilizada en la investigación y desarrollo de sistemas de recomendación, y sus aplicaciones abarcan una variedad de escenarios. Uno de sus usos principales es la implementación de filtrado colaborativo, tanto basado en usuarios como en ítems. En el filtrado colaborativo basado en usuarios, se recomiendan ítems que han sido preferidos por usuarios con gustos similares, mientras que en el basado en ítems, se recomiendan ítems que son similares a los que el usuario ya ha preferido. Este enfoque es especialmente útil en plataformas donde la interacción del usuario con los ítems (como películas, canciones o productos) es el principal indicador de sus preferencias.

  Además de la implementación de algoritmos, Surprise destaca por su capacidad para evaluar modelos de recomendación de manera rigurosa. La librería ofrece métricas como el error cuadrático medio (RMSE), el error absoluto medio (MAE) y la precisión en las recomendaciones (precision@k), que permiten a los desarrolladores comparar diferentes algoritmos y seleccionar el que mejor se adapte a sus necesidades. Estas métricas son fundamentales para garantizar que las recomendaciones sean precisas y relevantes para los usuarios.

  Otra aplicación importante de Surprise es la optimización de hiperparámetros. La librería incluye herramientas para realizar validación cruzada, lo que permite ajustar los modelos y encontrar la combinación óptima de parámetros. Esto es especialmente útil en entornos donde la precisión de las recomendaciones es crítica, como en plataformas de comercio electrónico o servicios de streaming, donde una recomendación incorrecta puede llevar a una mala experiencia del usuario.

  Surprise también se integra fácilmente con otras librerías de machine learning, como Scikit-learn, lo que facilita la creación de pipelines complejos y la combinación de diferentes técnicas de aprendizaje automático. Por ejemplo, es posible combinar el filtrado colaborativo con técnicas de filtrado basado en contenido, donde se utilizan características específicas de los ítems (como el género de una película o la categoría de un producto) para mejorar las recomendaciones. Esta flexibilidad hace que Surprise sea una herramienta versátil para abordar una amplia gama de problemas de recomendación.

  

  Hablemos ahora un poco sobre las ventajas y las desventajas que tiene utilizar la libreria Surprise, aqui abajo de las enlisto para que sea aun mas sencillo.

  Ventajas

  • Facilidad de Uso: Surprise está diseñada para ser intuitiva y fácil de usar, incluso para aquellos que no tienen una amplia experiencia en machine learning. Su API es clara y bien documentada, lo que facilita la implementación de modelos de recomendación.
  • Algoritmos Predefinidos: La librería incluye una variedad de algoritmos de recomendación predefinidos, como SVD (Descomposición en Valores Singulares), KNN (K-Nearest Neighbors), y NMF (Factorización de Matrices No Negativas), lo que permite a los usuarios experimentar con diferentes enfoques sin necesidad de implementarlos desde cero.
  • Evaluación Rigurosa: Surprise ofrece herramientas robustas para la evaluación de modelos, incluyendo la capacidad de realizar validación cruzada y calcular métricas de rendimiento de manera sencilla. Esto es crucial para garantizar que los modelos de recomendación sean precisos y confiables.
  • Comunidad Activa: Aunque Surprise no es tan popular como otras librerías de machine learning, cuenta con una comunidad activa de usuarios y contribuidores que proporcionan soporte y actualizaciones regulares. Esto asegura que la librería siga evolucionando y mejorando con el tiempo.

  Desventajas

  • Limitaciones en la Escalabilidad: Surprise está diseñada para conjuntos de datos de tamaño moderado. Para conjuntos de datos muy grandes, puede no ser la mejor opción debido a limitaciones en la escalabilidad. En estos casos, puede ser necesario recurrir a otras herramientas más especializadas en big data.
  • Falta de Soporte para Datos No Estructurados: Surprise está optimizada para trabajar con datos estructurados en forma de matrices de usuario-ítem. No ofrece soporte nativo para datos no estructurados, como texto o imágenes, lo que puede limitar su aplicabilidad en algunos escenarios.
  • Dependencia de NumPy y SciPy: Aunque esta dependencia es una ventaja en términos de eficiencia, también puede ser una desventaja para aquellos que no están familiarizados con estas librerías, ya que puede requerir un aprendizaje adicional.

  Antes de culminar queria presentarles de forma practica un pequeño ejemplo de como implementar un sistema de recomendacion sencillo utilizando Surprise basado en filtrado colaborativo.

  Primero instalamos la libreria para poder darle uso.

  !pip install surprise

  Ahora ejecutamos lo siguiente:

  # Importar las librerías necesarias
  from surprise import Dataset
  from surprise import Reader
  from surprise import SVD
  from surprise.model_selection import cross_validate
  
  # Cargar un conjunto de datos de ejemplo (en este caso, el dataset MovieLens)
  data = Dataset.load_builtin('ml-100k')
  
  # Definir el algoritmo a utilizar (en este caso, SVD)
  algo = SVD()
  
  # Realizar validación cruzada y evaluar el modelo
  cross_validate(algo, data, measures=['RMSE', 'MAE'], cv=5, verbose=True)
  
  # Entrenar el modelo con todo el conjunto de datos
  trainset = data.build_full_trainset()
  algo.fit(trainset)
  
  # Realizar una predicción para un usuario e ítem específicos
  user_id = '196'
  item_id = '302'
  pred = algo.predict(user_id, item_id)
  print(pred)

  Utilizamos el dataset de prueba llamado MovieLens para poder realizar un sistema de recomendacion de peliculas para el usuario 196 y poder predecir si le gustara el item o pelicula 302.

  

  El modelo SVD sencillo que hemos desarrollado ha logrado un rendimiento aceptable en la predicción de calificaciones, con un RMSE y MAE relativamente bajos. La predicción para el usuario 196 e ítem 302 es de 4.02, lo que sugiere que al usuario probablemente le gustaría este elemento.

  Conclusión

  La librería Surprise es una herramienta poderosa y versátil para la implementación de sistemas de recomendación en Python. Su facilidad de uso, combinada con una amplia gama de algoritmos predefinidos y herramientas de evaluación, la convierte en una opción atractiva tanto para investigadores como para desarrolladores. Sin embargo, es importante tener en cuenta sus limitaciones, especialmente en términos de escalabilidad y soporte para datos no estructurados.

  En resumen, si buscas una librería especializada en sistemas de recomendación que sea fácil de usar pero a la vez potente, Surprise es una excelente opción que vale la pena explorar. Ya sea que estés trabajando en un proyecto personal o en una aplicación comercial, Surprise puede ayudarte a construir modelos de recomendación efectivos y robustos. Con su combinación de algoritmos avanzados y herramientas de evaluación, Surprise se posiciona como una de las mejores opciones para aquellos que desean adentrarse en el fascinante mundo de los sistemas de recomendación.

  

February 04, 2025

• Fedora Community Blog Balkan Computer Congress, Novi Sad, Serbia

  BalCCon 2k24 – Invisible Path

  Fedora had a booth at BalCCon for the 8th time in a row. I’m personally very happy that we kept this streak as the first BalCCon where Fedora had presence is when I first became Ambassador in Serbia . I’m not aware of any other booths that had such a strong presence.

  For those unaware of this conference, it is focused on: hacking, information security, privacy, technology & society, making, lock-picking, and electronic arts. For a sharp eye, these are well-rounded topics for Free Software-oriented people and that makes it rather important conference in the region.
  In addition to all that, people that organize these events are extremely welcoming and heart-warming people! Working in tandem: founders, volunteers, and speakers – all show teamwork in very challenging times, both now as well as in the past… For an untrained eye it would seem that every BalCCon is a smooth sailing, but the truth is that there is a lot of effort and sacrifice required in realizing it. Every single person behind it, is a devoted, humble, and passionate contributor to the event.

  Attendees range from teenagers, students, younger and older adults all interested in learning, sharing and socializing with each others. In other words, the conference is not solely focused on lectures and workshops, but also on bringing similar-minded people together and providing them a safe place to connect.

  Fun is also huge part of the event as there is a karaoke evening (don’t miss that one ) and a rakia tasting and sharing night adequately named “Rakija leaksâ€�.

  At Fedora booth we try to engage people and encourage questions, to better understand what people like and dislike, to provide them guidance and invite them to join the community. We always keep the positive attitude towards all Free and Open Source Software and never fuel or support distro-wars. We love Fedora, but that doesn’t exclude love towards other distros as well (it just may not be as strong ).

  This approach had an impact that many non-Fedora users liked to talk to us and stuck around. That relationship grown to constructive discussions about strengths of Fedora and their OSes of choice. Many of them converted over time , or at least found a perfect sweet-spot for Fedora in their everyday life.

  Due to the import customs in Serbia, swag has been a hit and miss sometimes, but we try to keep the booth entertaining even in the absence of much-adored stickers.

  This year we’ve had a revamp of our booth with new Fedora logo for the roll-up banners and the table cloth. And it was at a perfect time, as Fedora booth was visible in an article of country’s most popular printed IT magazine Svet Kompjutera.

  This was all due to the amazing support from jwflory who displayed great amount of innovative and pro-active energy!

  Booth appearance has evolved over the years and become more and more inviting to everyone. An organizing volunteer even approached me to say that people’ve been asking if Fedora will have a booth again this year, as they found it very interesting – not only from the Project’s aspect, but also because, since the first year we tried to bring something that would draw people to come and talk to us.

  To give some examples:

  • Awesome demo of touchless gaming concept by our dear thunderbirdtr (2015)
  • Fedora on handheld touchscreen devices (2018)
  • AAA Gaming on Fedora out-of-the box (with RPM Fusion only) (2022)
  • Introduction of Fedora cookies (2023)
  • Fedora baby (2024)

  There are plans and ideas for future booths too, such as SyncStar setup, SELinux challenge box, DIY pin machine, other quizes, …

  Here is the timeline in photos from 2015 – 2024 (there are missing photos due to, either COVID, or just an unfortunate oversight on my end):

  

  

  

  

  

  

  

  Huge thanks for the support from jwflory, thunderbirdtr, nmilosev, nsukur, bitlord, and especially to my dear wife littlecat that makes the booth incredibly appealing.

  If you’ve never been to Serbia, Novi Sad, or BalCCon, you should definitely consider visiting and we’ll do our best to be good hosts and dedicate some of our times just for you!

  The post Balkan Computer Congress, Novi Sad, Serbia appeared first on Fedora Community Blog.

February 03, 2025

• Ismael Olea A RightsStatements ontology

  

  At LaOficina we are currently working on a project to digitize family photographs and one of the challenges is the correct traceability of intellectual property. In this case we have encountered the difficulty of knowing the exact conditions of the received material, a situation that is not new and which is already addressed by the RightsStatements vocabulary, which includes 12 terms that are used, among others, by the Europeana community. Therefore, it is obvious that we need to add this vocabulary to our Wikibase Suite instance. By the way, as an exercise, I have taken the opportunity to compose it from scratch as an independent OWL ontology. It is very simple, but probably it has some conceptual flaws. If it is useful to someone, please use it without restrictions: righstatements-ontology.ttl

  If you find something wrong please reach me.

• Christian F.K. Schaller Looking ahead at 2025 and Fedora Workstation and jobs on offer!

  So a we are a little bit into the new year I hope everybody had a great break and a good start of 2025. Personally I had a blast having gotten the kids an air hockey table as a Yuletide present :). Anyway, wanted to put this blog post together talking about what we are looking at for the new year and to let you all know that we are hiring.

  Artificial Intelligence
  One big item on our list for the year is looking at ways Fedora Workstation can make use of artificial intelligence. Thanks to IBMs Granite effort we know have an AI engine that is available under proper open source licensing terms and which can be extended for many different usecases. Also the IBM Granite team has an aggressive plan for releasing updated versions of Granite, incorporating new features of special interest to developers, like making Granite a great engine to power IDEs and similar tools. We been brainstorming various ideas in the team for how we can make use of AI to provide improved or new features to users of GNOME and Fedora Workstation. This includes making sure Fedora Workstation users have access to great tools like RamaLama, that we make sure setting up accelerated AI inside Toolbx is simple, that we offer a good Code Assistant based on Granite and that we come up with other cool integration points.

  Wayland
  The Wayland community had some challenges last year with frustrations boiling over a few times due to new protocol development taking a long time. Some of it was simply the challenge of finding enough people across multiple projects having the time to follow up and help review while other parts are genuine disagreements of what kind of things should be Wayland protocols or not. That said I think that problem has been somewhat resolved with a general understanding now that we have the ‘ext’ namespace for a reason, to allow people to have a space to review and make protocols without an expectation that they will be universally implemented. This allows for protocols of interest only to a subset of the community going into ‘ext’ and thus allowing protocols that might not be of interest to GNOME and KDE for instance to still have a place to live.

  The other more practical problem is that of having people available to help review protocols or providing reference implementations. In a space like Wayland where you need multiple people from multiple different projects it can be hard at times to get enough people involved at any given time to move things forward, as different projects have different priorities and of course the developers involved might be busy elsewhere. One thing we have done to try to help out there is to set up a small internal team, lead by Jonas Ådahl, to discuss in-progress Wayland protocols and assign people the responsibility to follow up on those protocols we have an interest in. This has been helpful both as a way for us to develop internal consensus on the best way forward, but also I think our contribution upstream has become more efficient due to this.

  All that said I also believe Wayland protocols will fade a bit into the background going forward. We are currently at the last stage of a community ‘ramp up’ on Wayland and thus there is a lot of focus on it, but once we are over that phase we will probably see what we saw with X.org extensions over time, that for the most time new extensions are so niche that 95% of the community don’t pay attention or care. There will always be some new technology creating the need for important new protocols, but those are likely to come along a relatively slow cadence.

  High Dynamic Range
  

  

  HDR support in GNOME Control Center

  As for concrete Wayland protocols the single biggest thing for us for a long while now has of course been the HDR support for Linux. And it was great to see the HDR protocol get merged just before the holidays. I also want to give a shout out to Xaver Hugl from the KWin project. As we where working to ramp up HDR support in both GNOME Shell and GTK+ we ended up working with Xaver and using Kwin for testing especially the GTK+ implementation. Xaver was very friendly and collaborative and I think HDR support in both GNOME and KDE is more solid thanks to that collaboration, so thank you Xaver!

  Talking about concrete progress on HDR support Jonas Adahl submitted merge requests for HDR UI controls for GNOME Control Center. This means you will be able to configure the use of HDR on your system in the next Fedora Workstation release.

  PipeWire
  I been sharing a lot of cool PipeWire news here in the last couple of years, but things might slow down a little as we go forward just because all the major features are basically working well now. The PulseAudio support is working well and we get very few bug reports now against it. The reports we are getting from the pro-audio community is that PipeWire works just as well or better as JACK for most people in terms of for instance latency, and when we do see issues with pro-audio it tends to be more often caused by driver issues triggered by PipeWire trying to use the device in ways that JACK didn’t. We been resolving those by adding more and more options to hardcode certain options in PipeWire, so that just as with JACK you can force PipeWire to not try things the driver has problems with. Of course fixing the drivers would be the best outcome, but for some of these pro-audio cards they are so niche that it is hard to find developers who wants to work on them or who has hardware to test with.

  We are still maturing the video support although even that is getting very solid now. The screen capture support is considered fully mature, but the camera support is still a bit of a work in progress, partially because we are going to a generational change the camera landscape with UVC cameras being supplanted by MIPI cameras. Resolving that generational change isn’t just on PipeWire of course, but it does make the a more volatile landscape to mature something in. Of course an advantage here is that applications using PipeWire can easily switch between V4L2 UVC cameras and libcamera MIPI cameras, thus helping users have a smooth experience through this transition period.
  But even with the challenges posed by this we are moving rapidly forward with Firefox PipeWire camera support being on by default in Fedora now, Chrome coming along quickly and OBS Studio having PipeWire support for some time already. And last but not least SDL3 is now out with PipeWire camera support.

  MIPI camera support
  Hans de Goede, Milan Zamazal and Kate Hsuan keeps working on making sure MIPI cameras work under Linux. MIPI cameras are a step forward in terms of technical capabilities, but at the moment a bit of a step backward in terms of open source as a lot of vendors believe they have ‘secret sauce’ in the MIPI camera stacks. Our works focuses mostly on getting the Intel MIPI stack fully working under Linux with the Lattice MIPI aggregator being the biggest hurdle currently for some laptops. Luckily Alan Stern, the USB kernel maintainer, is looking at this now as he got the hardware himself.

  Flatpak
  Some major improvements to the Flatpak stack has happened recently with the USB portal merged upstream. The USB portal came out of the Sovereign fund funding for GNOME and it gives us a more secure way to give sandboxed applications access to you USB devcices. In a somewhat related note we are still working on making system daemons installable through Flatpak, with the usecase being applications that has a system daemon to communicate with a specific piece of hardware for example (usually through USB). Christian Hergert got this on his todo list, but we are at the moment waiting for Lennart Poettering to merge some pre-requisite work into systemd that we want to base this on.

  Accessibility
  We are putting in a lot of effort towards accessibility these days. This includes working on portals and Wayland extensions to help facilitate accessibility, working on the ORCA screen reader and its dependencies to ensure it works great under Wayland. Working on GTK4 to ensure we got top notch accessibility support in the toolkit and more.

  GNOME Software
  Last year Milan Crha landed the support for signing the NVIDIA driver for use on secure boot. The main feature Milan he is looking at now is getting support for DNF5 into GNOME Software. Doing this will resolve one of the longest standing annoyances we had, which is that the dnf command line and GNOME Software would maintain two separate package caches. Once the DNF5 transition is done that should be a thing of the past and thus less risk of disk space being wasted on an extra set of cached packages.

  Firefox
  Martin Stransky and Jan Horak has been working hard at making Firefox ready for the future, with a lot of work going into making sure it supports the portals needed to function as a flatpak and by bringing HDR support to Firefox. In fact Martin just got his HDR patches for Firefox merged this week. So with the PipeWire camera support, Flatpak support and HDR support in place, Firefox will be ready for the future.

  We are hiring! looking for 2 talented developers to join the Red Hat desktop team
  We are hiring! So we got 2 job openings on the Red Hat desktop team! So if you are interested in joining us in pushing the boundaries of desktop linux forward please take a look and apply. For these 2 positions we are open to remote workers across the globe and while the job adds list specific seniorities we are somewhat flexible on that front too for the right candidate. So be sure to check out the two job listings and get your application in! If you ever wanted to work fulltime on GNOME and related technologies this is your chance.

February 01, 2025

• Kevin Fenzi Bits from late jan 2025

  

  January has gone by pretty fast. Here's some longer form thoughts about a few things that happened this last week.

  Mass updates/reboots

  We did a mass update/reboot cycle on (almost) all our instances. The last one was about 2 months ago (before the holidays), so we were due. We do apply security updates weekdayly (ie, monday - friday), but we don't apply bugfix updates except for this scheduled windows. Rebooting everything makes sure everything is on the latest kernel versions and also ensures that if we had to reset something for other reasons it would come back up in the correct/desired/working state. I did explore the idea of having things setup so we could do these sorts of things without an outage window at all, but at the time (a few years ago) the sticking point was database servers. It was very possible to setup replication, but it was all very fragile and required manual intervention to make sure failover/failback worked right. There's been a lot of progress in that area though, so later this year it might be time to revisit that.

  We also use these outage windows to do some reinstalls and dist-upgrades. This time I moved a number of things from f40 to f41, and reinstalled the last vmhost we had still on rhel8. That was a tricky one as it had our dhcp/tftp vm and our kickstarts/repos vm. So, I live migrated them to another server, did the reinstall and migrated them back. It all went pretty smoothly.

  There was some breakage with secure boot signing after these upgrades, but it turned out to be completely my fault. The _last_ upgrade cycle, opensc changed the name of our token. From: 'OpenSC Card (Fedora Signer)' to 'OpenSC Card'. The logic upstream being "Oh, if you only have one card, you don't need to know the actual token name". Which is bad for a variety of reasons, like if you suddenly add another card, or swap cards. In any case I failed to fix my notes on that and was trying the old name and getting a confusing and bad error message. Once I managed to fix it out everything was working again.

  Just for fun, here's our top 5 os versions by number:

  • 237 Fedora 41

  • 108 RHEL 9.5

  • 31 Fedora 40

  • 23 RHEL 8.10

  • 4 RHEL 7.9

  The 7.9 ones will go away once fedmsg and github2fedmsg are finally retired. (Hopefully soon).

  Datacenter Move

  A bunch of planning work on the upcoming datacenter move. I'm hoping next week to work a lot more on a detailed plan. Also, we in infrastructure should kick off some discussions around if there's anything we can change/do while doing this move. Of course adding in too much change could be bad given the short timeline, but there might be some things to consider.

  I also powered off 11 of our old arm servers. They had been disabled in the buildsystem for a while to confirm we didn't really need them, so I powered them off and saved us some energy usage.

  riscv-koji seconday hub

  The riscv-koji seconday hub is actually installed and up now. However, there's still a bunch of things to do:

  • Need to setup authentication so people/I can login to it.

  • Need to install some buildvm-x86 builders to do newrepos, etc

  • Need to install a composer to build images and such on

  • Next week's riscv sig meeting hopefully we can discuss steps after that. Probibly we would just setup tags/targets/etc and import a minimal set of rpms for a buildroot

  • Need to figure out auth for builders and add some.

  Overall progress finally. Sorry I have been a bottleneck on it, but soon I think lots of other folks can start in on working on it.

  power9 lockups

  We have been having anoying lockups of our power9 hypervisors. I filed https://bugzilla.redhat.com/show_bug.cgi?id=2343283 on that. In the mean time I have been moving them back to the 6.11.x kernels which don't seem to have the problem. I did briefly try a 6.13.0 kernel, but the network wasn't working there. I still need to file a bug on that when I can take one down and gather debugging info. It was the i40e module not being able to load due to some kind of memory error. ;(

  Chat and work items

  One thing that was bugging me last year is that I get a lot of notifications on chat platforms (in particular slack and matrix) where someone asks me something or wants me to do something. Thats perfectly fine, I'm happy to help. However, when I sit down in the morning, I usually want to look at whats going on and prioritze things, not get sidetracked into replying/working on something thats not the most important issue. This resulted in me trying to remember which things where needed responses and sometimes missing going back to them or getting distracted by them.

  So, a few weeks ago I started actually noting things like that down as I came to them, then after higher pri things were taken care of, I had a nice list to go back through and hopefully not miss anything.

  It's reduced my stress, and I'd recommend it for anyone with similar workflows.

  comments? additions? reactions?

  As always, comment on mastodon: https://fosstodon.org/@nirik/113930147248831003

• Fedora fans اجرای هوش مصنوعی با استفاده از Ollama و Open WebUI

  

  هوش مصنوعی، به‌ویژه هوش مصنوعی مولد (Generative AI)، به‌سرعت در حال پیشرفت است و دسترسی به آن برای کاربران عادی روزبه‌روز آسان‌تر می‌شود. با ظهور مدل‌های زبانی بزرگ (LLM) مانند GPT و LLaMA، تمایل به اجرای این مدل‌ها به‌صورت محلی روی سخت‌افزار شخصی افزایش یافته است. این مقاله راهنمای ساده‌ای برای راه‌اندازی Ollama (ابزاری برای […]

  The post اجرای هوش مصنوعی با استفاده از Ollama و Open WebUI first appeared on طرفداران فدورا.

January 31, 2025

• Fedora Community Blog Infra and RelEng Update – Week 05 2025

  This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. 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: – 27th January – 31th January 2025

  

  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:
    • Planned Outage – updates / reboots – 2025-01-29 21:00UTC
    • [CommOps] Open Data Hub on Communishift
    • retire easyfix
    • bvmhost-p09-03 ends in emergency mode
    • Add StartInstanceRefresh permission for fedora-ci-testing-farm user in AWS
    • Deploy Element Server Suite operator in staging
    • Create CentOS calendar
    • Pagure returns error 500 trying to open a PR on https://src.fedoraproject.org/rpms/python-setuptools-gettext
    • a real domain name for konflux
    • Retirement of `monitor-dashboard` tracker
    • Create a POC integration in Konflux for fedora-infra/webhook-to-fedora-messaging
    • Retirement of `monitor-gating` tracker
    • maubot-meetings bot multi line paste is cut
    • setup ipa02.stg and ipa03.stg again as replicas
    • Manage our new testing.farm domain via AWS Route53
    • Add support for creating RDS instances under `testing-farm-` prefix
    • Move OpenShift apps from deploymentconfig to deployment
    • The process to update the OpenH264 repos is broken
    • httpd 2.4.61 causing issue in fedora infrastructure
    • Support allocation dedicated hosts for Testing Farm
    • fedorapeople.org directory listing theme needs refreshing
    • EPEL minor version archive repos in MirrorManager
    • vmhost-x86-copr01.rdu-cc.fedoraproject.org DOWN
    • Add yselkowitz to list to notify when ELN builds fail
    • Cleaning script for communishift
    • rhel7 eol
    • move resultsdb-ci-listener deployment pipeline
    • rhel7 EOL – github2fedmsg
    • Move from iptables to firewalld
    • Help me move my discourse bots to production?
    • fedmsg -> fedora-messaging migration tracker
    • rhel9 adoption
    • Create monitoring tool for rabbitmq certificates
    • Replace Nagios with Zabbix in Fedora Infrastructure
    • Migration of registry.fedoraproject.org to quay.io
    • Commits don’t end up on the scm-commits list
  • Done:
    • Can we get passkey auth support for FAS logins
    • fedora-messaging times out when pushing to a fork on src.f.o
    • Problem with adding new admin to a star project
    • Messages sent to test-request@lists.fedoraproject.org are failing to arrive
    • Please generate the Fedora 44 gpg key
    • Opt-in for AWS region to mx-central-1 acct:125523088429
    • Opt-in for AWS region to ap-southeast-7 acct:125523088429
    • Need help investigating cfp.fedoraproject.org email delivery failure to michel@michel-slm.name (pretalx.com works fine)
    • distgit-bugzilla-sync poddlers in both staging and prod downloading a lot from production
    • Bodhi is being flooded with invalid requests
    • builds failing due to full disks
    • Inactive packagers policy for the F41 release cycle
    • reinstall memcached instances with rhel9
    • many CentOS Stream repos on mirrors have bad hashes
    • Impossible to push/share new AMIs (CentOS Stream) due to reached quota
    • Direct database access to message bus date for Greg Sutcliffe
    • Fedora group on Gitlab.com requires 2FA
    • RFE: fedoras container image register change
    • rpm-ostree error (503) from hetzner to

  CentOS Infra including CentOS CI

  • In progress:
    • Adapt zabbix-agent ansible role for new hardware raid controller
    • Setup hyperscale 10 image build tags
    • [spike] : investigating options/alternatives for the upcoming DC move
    • Zuul CI namespace
    • Testing Jenkins – c10s x86_64 metal doesn’t provision
    • Release Improvements
  • Done:
    • Please whitelist mirror.plusline.net (formerly ftp.plusline.net)
    • Setup hyperscale-kernel tag for c10s

  Release Engineering

  • In progress:
    • please remove unwanted rpmdevtools commit accidentally pushed to rawhide branch
    • 300+ F42FTBFS bugzillas block the F41FTBFS tracker
    • Unretire tachyon
    • Unretire ethos
    • Fedora 42 Mass Rebuild Tracker
    • Quay.io repository for fedora-bootc-tier-x
    • Missing rawhide branch for recently created package ‘pybind11-json’
    • F42 Self-Contained Change: Switch to EROFS for Live Media
    • Please remove two branches from octave-iso2mesh
    • Send compose reports to a to-be-created separate ML
    • .sqlite metadata missing in f41-updates and f41-updates-testing repositories
    • F42 system-wide change: GNU Toolchain update for F42 https://fedoraproject.org/wiki/Changes/GNUToolchainF42
    • Delete “firefox-fix” branch in xdg-desktop-portal
    • please create epel10 based el10-openjdk tag
    • Could we have fedoraproject-updates-archive.fedoraproject.org for Rawhide?
    • Investigate and untag packages that failed gating but were merged in via mass rebuild
    • a few mass rebuild bumps failed to git push – script should retry or error
    • Renaming distribution media for Fedora Server
    • Package retirements are broken in rawhide
    • Implement checks on package retirements
    • Untag containers-common-0.57.1-6.fc40
    • orphan-all-packages.py should remove bugzilla_contact entries from fedora-scm-requests as well
    • Packages that fail to build SRPM are not reported during the mass rebuild bugzillas
    • When orphaning packages, keep the original owner as co-maintainer
    • Create an ansible playbook to do the mass-branching
    • RFE: Integration of Anitya to Packager Workflow
    • Cleaning old stuff from koji composes directories
    • Fix tokens for ftbfs_weekly_reminder. script
    • Update bootloader components assignee to “Bootloader Engineering Team”for Improved collaboration
  • Done:
    • Stalled EPEL package request: python-pytest-cov
    • Create missed Rawhide (F42) update for miniupnpd
    • Merge side tag f42-build-side-103691
    • untag qt5-5.15.16-2.fc42 and qt5-qtbase-5.15.16-2.fc42
    • No Fedora Budgie Atomic compose since 41.20241114.0
    • Make ppc64le Server_KVM image build not take two hours

  If you have any questions or feedback, please respond to this report or contact us on #redhat-cpe channel on matrix.

  The post Infra and RelEng Update – Week 05 2025 appeared first on Fedora Community Blog.

• Remi Collet 🎲 PHP version 8.3.17RC1 and 8.4.4RC2

  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.4.4RC2 are available

  • as base packages in the remi-modular-test for Fedora 39-41 and Enterprise Linux ≥ 8
  • as SCL in remi-test repository

  RPMs of PHP version 8.3.17RC1 are available

  • as base packages in the remi-modular-test for Fedora 39-41 and Enterprise Linux ≥ 8
  • as SCL in remi-test repository

  ℹ️ The packages are available for x86_64 and aarch64.

  ℹ️ PHP version 8.2 is now in security mode only, so no more RC will be released.

  ℹ️ Installation: follow the wizard instructions.

  ℹ️ Announcements:

  • PHP 8.4.4RC2 available for testing
  • PHP 8.3.17RC1 available for testing

  Parallel installation of version 8.4 as Software Collection:

  yum --enablerepo=remi-test install php84

  Parallel installation of version 8.3 as Software Collection:

  yum --enablerepo=remi-test install php83

  Update of system version 8.4:

  dnf module switch-to php:remi-8.4
  dnf --enablerepo=remi-modular-test update php\*

  Update of system version 8.3:

  dnf module switch-to php:remi-8.3
  dnf --enablerepo=remi-modular-test update php\*

  ℹ️ Notice:

  • version 8.4.4RC2 is in Fedora rawhide for QA
  • EL-10 packages are built using RHEL-10.0-beta
  • EL-9 packages are built using RHEL-9.5
  • EL-8 packages are built using RHEL-8.10
  • oci8 extension uses the RPM of the Oracle Instant Client version 23.7 on x86_64 or 19.25 on aarch64
  • intl extension uses libicu 74.2
  • RC version is usually the same as the final version (no change accepted after RC, exception for security fix).
  • versions 8.3.17 and 8.4.4 are planed for February 13th, in 2 weeks.

  Software Collections (php83, php84)

  

  

  Base packages (php)

  

  

• Kushal Das Pixelfed on Docker

  I am running a Pixelfed instance for some time now at https://pixel.kushaldas.photography/kushal. This post contains quick setup instruction using docker/containers for the same.

  

  Copy over .env.docker file

  We will need .env.docker file and modify it as required, specially the following, you will have to write the values for each one of them.

  APP_NAME=
  APP_DOMAIN=
  OPEN_REGISTRATION="false"   # because personal site
  ENFORCE_EMAIL_VERIFICATION="false" # because personal site
  DB_PASSWORD=
  
  # Extra values to db itself
  MYSQL_DATABASE=
  MYSQL_PASSWORD=
  MYSQL_USER=
  
  CACHE_DRIVER="redis"
  BROADCAST_DRIVER="redis"
  QUEUE_DRIVER="redis"
  SESSION_DRIVER="redis"
  
  REDIS_HOST="redis"
  
  ACITIVITY_PUB="true"
  
  LOG_CHANNEL="stderr"
  

  The actual docker compose file:

  ---
  
  services:
    app:
      image: zknt/pixelfed:2025-01-18
      restart: unless-stopped
      env_file:
        - ./.env
      volumes:
        - "/data/app-storage:/var/www/storage"
        - "./.env:/var/www/.env"
      depends_on:
        - db
        - redis
      # The port statement makes Pixelfed run on Port 8080, no SSL.
      # For a real instance you need a frontend proxy instead!
      ports:
        - "8080:80"
  
    worker:
      image: zknt/pixelfed:2025-01-18
      restart: unless-stopped
      env_file:
        - ./.env
      volumes:
        - "/data/app-storage:/var/www/storage"
        - "./.env:/var/www/.env"
      entrypoint: /worker-entrypoint.sh
      depends_on:
        - db
        - redis
        - app
      healthcheck:
        test: php artisan horizon:status | grep running
        interval: 60s
        timeout: 5s
        retries: 1
  
    db:
      image: mariadb:11.2
      restart: unless-stopped
      env_file:
        - ./.env
      environment:
        - MYSQL_ROOT_PASSWORD=CHANGE_ME
      volumes:
        - "/data/db-data:/var/lib/mysql"
  
    redis:
      image: zknt/redis
      restart: unless-stopped
      volumes:
        - "redis-data:/data"
  
  volumes:
    redis-data:
  

  I am using nginx as the reverse proxy. Only thing to remember there is to pass .well-known/acme-challenge to the correct directory for letsencrypt, the rest should point to the contianer.

• Josef Strzibny Setting up Cloudflare R2 buckets for Active Storage

  Rails comes with a built-in support for saving and uploading files to S3 and S3-compatible storage services in Active Storage. Here’s how to set up Cloudflare R2.

  Cloudflare R2

  To start using Cloudflare R2, select R2 Object Storage from the menu on the left navbar. If you are on free plan you’ll need to subscribe first.

  Then you can click + Create bucket and give your bucket a name. Choose meaningful names for your buckets. I usually append the environment to the name.

  Cloudflare will auto assign your bucket location based on your actual location and providing a hint might not work. Not great doing this on holidays.

  TIP: If you are hosting in EU, you can at least choose Specify jurisdiction and force it to be within EU.

  Then on the bucket page choose Settings and include the following CORS:

  [
    {
      "AllowedOrigins": [
        "*"
      ],
      "AllowedMethods": [
        "PUT"
      ],
      "AllowedHeaders": [
        "*"
      ],
      "ExposeHeaders": [
        "Origin", "Content-Type", "Content-MD5", "Content-Disposition"
      ],
      "MaxAgeSeconds": 3600
    }
  ]
  

  Once done click on API next to the + Create Bucket button. Select Manage API tokens and create a new token.

  Note all secrets and most importantly access key, access key secret and URL.

  Rails configuration

  Install Active Storage and configure config/storage.yml similarly to the following:

  test:
    service: Disk
    root: <%= Rails.root.join("tmp/storage") %>
  
  local:
    service: Disk
    root: <%= Rails.root.join("storage") %>
  
  cloudflare_dev:
    service: S3
    endpoint: https://[HASH].eu.r2.cloudflarestorage.com
    access_key_id: <%= ENV["R2_ACCESS_KEY"] %>
    secret_access_key: <%= ENV["R2_SECRET_ACCESS_KEY"] %>
    bucket: app-dev
    region: auto
  
  cloudflare_production:
    endpoint: https://[HASH].eu.r2.cloudflarestorage.com
    access_key_id: <%= ENV["R2_ACCESS_KEY"] %>
    secret_access_key: <%= ENV["R2_SECRET_ACCESS_KEY"] %>
    bucket: app
    region: auto
  
  

  To connect Cloudflare we’ll need an endpoint, access_key_id, secret_access_key, and region. You can use environment variables or Rails Credentials.

  Note that unlike for Amazon S3 where we fill in the region and Digital Ocean Spaces where the region is unused, we set it to auto.

  I usually set up two different backends, one for development and one for production:

  # config/environments/development.rb
  config.active_storage.service = :cloudflare_dev
  
  # config/environments/production.rb
  config.active_storage.service = :cloudflare_production
  

  And that’s really it!

January 30, 2025

• ! Avi Alkalay ¡ Ensuring health of your NAS hard drives with SMART

  Here are simple good practices to ensure health of your HDDs, using SMART.

  I run a home server since many decades ago with multiple services such as:

  • Jellyfin media server
  • NextCloud for family file storage
  • Samba file server
  • Home Assistant for home automation and bridge with Apple Home
  • Virtual machines and Podman containers with various other services

  Hardware setup is:

  • Fedora Linux 40 on Intel NUC11TNBi3 with 16GB RAM and 256GB SSD
  • Terramaster D6-320 storage enclosure with 6 SATA HDD, connected to computer by a USB-C cable; no RAID, just a bunch of disks I sporadically add whenever I need more space
  • Autorsync daily backup to an old OpenWRT Buffalo router with a 6TB external HDD, located off-site, in the home of a relative

  This server is critical for my family, yet several hard drives failed during all these years (that is why I have setup automated backups).

  It was not until recently that I learned how to monitor the health of these HDDs using SMART. Get it installed with package smartmontools.

  

  HDD manual health self-tests

  When you get a new HDD, after connecting but before putting it into production, you must run a self-health check with command:

  smartctl -t long /dev/sdz

  Where /dev/sdz is the device name of your new HDD. This test will take more than 10 hours and can be done even with the HDD in use, but it will degrade performance, so I prefer to unmount all filesystems first.

  You should run this health check sporadically from time to time.

  You can also run 10 minutes health checks without bothering to take your services offline:

  smartctl -t short /dev/sdz

  To see results of these tests, I prefer using Alexander Shaduri’s GSmartControl GUI, even if smartctl command can also display results. Here is the view of one HDD with the completion status of the health checks we triggered by the smartctl commands above, the Self-Tests tab.

  

  As a general good practice, you must immediately stop using a HDD if you get many errors in the Error Log tab.

  SMART error messages are very confusing and proprietary, and I have seen HDDs marked as healthy even if they present many error messages. So again, as a general good practice, if smartctl -l error /dev/sdz output is very long and is not a simple No errors logged, it is time to migrate data off of the HDD and replace it.

  Automated health tests

  The smartmontools package also installs a service that checks HDD health daily and sends a report by e-mail. On Fedora Linux this is activated by simply installing the package, but is useless if your system can’t send e-mails, which is the way reports are delivered. So make sure you enable your server to send e-mails. There are many ways of doing this, the simplest one is using Gmail as relay.

  If your HDD is starting to fail, you’ll get an e-mail from the SMART daemon. If that happens, you must run more extensive health checks as described above. And check your backups and move your data off of the failing HDD.

  Also, you should check the warranty of your HDDs. The more premium product lines of Seagate (IronWolf) and Wester Digital (Red) offer 3-year warranty and you should make sure you’ll get these when you buy it. Use your HDD serial number to check if warranty coverage is still valid on Seagate and Western Digital websites. You can fill some forms and on the manufacturer’s website to get a brand new replacement HDD.

January 29, 2025

• Peter Czanik Running syslog-ng PE in RHEL UBI

  Recently I have posted a Dockerfile to run syslog-ng in an Alma Linux container. I got some encouraging feedback, so this week I experimented with syslog-ng Premium Edition (PE) in a RHEL UBI (Universal Base Image) container. While this is not officially supported by One Identity, we are really interested in your feedback.

  Before you begin

  If you do not have syslog-ng PE yet, you can get it at https://www.syslog-ng.com/register/115582/ . You also need RHEL with a valid subscription to build the container image. You need Podman and Buildah installed, and also git, unless you want to download files one by one.

  The files

  You can download the Dockerfile and the related files from GitHub from my personal repo at https://github.com/czanik/syslog-ng-pe-ubi.

  The Dockerfile contains all information needed to build the container image. Let’s check some of the most important lines from the file.

  FROM registry.access.redhat.com/ubi9/ubi-init

  This line means that we use the RHEL Universal Base Image as a base image. It has a couple of variants: “init” means that this image has systemd with service management included. It results in a slightly larger image size, but it also means that unlike the method described in the syslog-ng PE documentation, multiple services can run in the same container. In this case, syslog-ng starts automatically, but optionally you can also enable the syslog-ng Windows Event Collector (WEC) and the syslog-ng Prometheus exporter.

  ENV SNGRPM="syslog-ng-premium-edition-8.0.0-1+20250116+1752.rhel9.x86_64.rpm"

  Setting this environment variable ensures that you only have to set the syslog-ng PE installer filename only once.

  The next lines update software in the container, install syslog-ng PE and clean the package management system. (Note that even if we remove the syslog-ng PE installer, it persists in one of the lower layers, enlarging the final container image. I still need to find a workaround for this problem.)

  Next, files related to the syslog-ng Prometheus exporter are added. Only the syslog-ng service is enabled in the Dockerfile, and you can easily enable other services later. However, you can also add syslog-ng-wec and sngexporter here, so you do not have to enable these services manually for the container.

  Default ports related to syslog-ng PE are collected in the Dockerfile. Note that these are not automagically forwarded from the outside network to the containers. These are just reminders that these ports could be opened by the application(s) running in the container.

  The bundled syslog-ng.conf does not collect local logs but opens a couple of network sources.

  Building the container

  Once you set the name of the installer in the Dockerfile, and optionally also included other services to be enabled, you are ready to build the container. You can name it what you want or skip naming altogether. The following command builds a new container within a few minutes (depending on the network speed):

  docker build -t ubipe9 .

  Note that while I still use the command name “docker” in my examples, I actually use Podman and Buildah with a compatibility link.

  Running the container

  There are many options to run the container. You will most likely map some directories from the host or open some ports to collect logs from remote hosts. Here I show only a very basic command line. It starts syslog-ng in the background, and maps the license file into the container from the host:

  docker run -d --name=sng -v /data/license.txt:/opt/syslog-ng/etc/license.txt:Z ubipe9

  The license file is needed to run syslog-ng PE as a server. Without it, syslog-ng PE can save logs only from local log sources or run in relay mode (forward logs without saving them).

  Enabling and disabling services

  You have seen how to enable services in the Dockerfile. You can also enable (or disable) WEC or the Prometheus exporter from the command line. The container will keep the changed state as long as you do not rm it. Here is a sample session:

  [root@localhost syslog-ng-pe-ubi]# docker run -d --name=sng -v /data/license.txt:/opt/syslog-ng/etc/license.txt:Z ubipe9
  e09706c27aa4a10e83959030604473c9f3e2a0d45c8f011256d2a4ae03ba732e
  [root@localhost syslog-ng-pe-ubi]# docker exec -ti sng systemctl enable sngexporter
  Created symlink /etc/systemd/system/multi-user.target.wants/sngexporter.service → /usr/lib/systemd/system/sngexporter.service.
  [root@localhost syslog-ng-pe-ubi]# docker stop sng
  sng
  [root@localhost syslog-ng-pe-ubi]# docker start sng
  sng
  [root@localhost syslog-ng-pe-ubi]# docker exec -ti sng /bin/bash
  [root@e09706c27aa4 /]# ps aux
  USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
  root           1  0.5  0.3  22072 11648 ?        Ss   09:07   0:00 /sbin/init
  root          10  0.0  0.2  35748  9244 ?        Ss   09:07   0:00 /usr/lib/systemd/systemd-journald
  root          16  3.1  0.8 375848 32272 ?        Ssl  09:07   0:00 /opt/syslog-ng/libexec/syslog-ng -F --enable-core
  root          21  0.6  0.5  25152 18944 ?        Ss   09:07   0:00 python3 /usr/local/bin/sng_exporter.py --socket-path=/opt/syslog-ng/var/syslog-ng.ctl
  root          25  0.0  0.0   4840  3712 pts/0    Ss   09:07   0:00 /bin/bash
  root          36  0.0  0.0   7552  3200 pts/0    R+   09:07   0:00 ps aux

  What is next?

  This blog is aimed at helping you to get started with syslog-ng PE in a RHEL UBI container. This is still experimental and not officially supported, but your feedback is very welcome, both the problem and success reports.

  -

  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.

• Cockpit Project Cockpit 332

  Cockpit is the modern Linux admin interface. We release regularly.

  Here are the release notes from Cockpit 332, cockpit-machines 327, cockpit-podman 100, and cockpit-files 15:

  cockpit/ws container: Include cockpit-files

  The cockpit/ws container now includes cockpit-files. When you log into a remote machine that does not have any Cockpit packages installed (package-less mode), the “Files” page is now available.

  Package-less session for all supported operating systems

  Cockpit 327 introduced support for connecting to remote machines without any installed Cockpit packages. That only worked if the local and remote machine had the same operating system version. This version extends this “package-less session” feature to all operating systems which Cockpit continuously tests. At the time of writing this includes:

  • Arch Linux
  • CentOS Stream 9, 10
  • Debian 12, testing/unstable
  • Fedora Linux 40, 41, 42 (rawhide)
  • Red Hat Enterprise Linux 8, 9, 10
  • Ubuntu 22.04 LTS, 24.04 LTS, 24.10

  This list will change over time, due to new distribution releases and the end of support for each version.

  Overview: Show system boot in metrics

  

  Machines: “Launch viewer” now uses correct address

  The “Launch viewer” button in a virtual machine’s “Console” card now uses the same address that Cockpit uses to connect to the virtual machine host. Previously, the button incorrectly attempted to connect to either the local machine where the browser is running (when the listening address was set to “localhost”) or to an invalid “0.0.0.0” address (when configured to listen to all interfaces).

  Podman: Automatically start podman.socket

  If podman.socket is not already running on the system or user session, cockpit-podman will now automatically start the unit. It is no longer necessary to manually start or enable the podman service.

  Podman: Improve quadlet compatibility

  Container-based services (aka: “quadlets”) are now labeled with a “service” badge in the containers overview. Additionally, the option to rename quadlets has been removed, as renaming must take place in the systemd service .container file, which are often found in /etc/containers/systemd/.

  

  Files: Show user:group in the footer

  The footer now shows the user and group of the current directory.

  

  Try it out

  Cockpit 332, cockpit-machines 327, cockpit-podman 100, and cockpit-files 15 are available now:

  • For your Linux system

  • Cockpit Client

  • Cockpit Source Tarball
  • cockpit Fedora 40
  • cockpit Fedora 41
  • cockpit-machines Source Tarball
  • cockpit-machines Fedora 41
  • cockpit-podman Source Tarball
  • cockpit-podman Fedora 41
  • cockpit-podman Fedora 40
  • cockpit-files Source Tarball
  • cockpit-files Fedora 41
  • cockpit-files Fedora 40

January 28, 2025

• suve's ramblings The little bool of doom

  A short story about debugging and how sometimes what's true is false. Starring everyone's favourite uncle, Undefined Behaviour.

January 27, 2025

• Felipe Borges The GNOME LATAM 2024 recordings are now live!

  In October 2024 some members of our community gathered in Medelin, Colombia, for another edition of GNOME Latam. Some of us joined remotely for a schedule packed with talks about GNOME and its ecosystem.

  The talks, in Spanish and Portuguese, are now published on YouTube. Check it out!

• The NeuroFedora Blog Next Open NeuroFedora meeting: 27 January 2025 1300 UTC

  

  Photo by William White on Unsplash.

  
  

  Please join us at the next regular Open NeuroFedora team meeting on Monday 27 January 2025 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, January 27, 2025 13:00 UTC'
  

  The meeting will be chaired by @ankursinha. The agenda for the meeting is:

  • New introductions and roll call.
  • Tasks from last meeting.
  • Open Pagure tickets.
  • Package health check.
  • Open package reviews check.
  • CompNeuro lab compose status check for Fedora 41/rawhide.
  • Neuroscience query of the week
  • Next meeting day, and chair.
  • Open floor.

  We hope to see you there!

• Adam Young gitlab section headings in python

  What a way to spend an evening.
  
  As I attempted to rewrite some Gitlab automation from bash to python, I stumbled over what should have been a trivial thing: collapsing section headers. They were not trivial.
  

  In bash the code to do a section header looks like this:

  section_start() {
      name="$1"
      description="${2:-$name}"
  
      echo -e "\e[0Ksection_start:`date +%s`:${name}[collapsed=true]\r\e[0K${description}"
  }
  

  But those escape sequences are not valid escape sequences in python. What they turn in to is non-intuitive either. Here is the code I ended up with:

  def section_start(name, description=None):
      if description is None:
          description = name
      escape = bytearray([27, 91, 48, 75])
      log_date = local["date"]("+%s").strip()
      message = "section_start:" + log_date + ":" + name + "[collapsed=true]\r"
      b = escape + message.encode('utf-8') + escape + description.encode('utf-8')
      sys.stdout.buffer.write(b)
      print()
  
  

  The print call in python accepts on a limited set of escape characters. It turns out that the “\e” in my original echo command is not one of them.

  To find out what was actually sent to the screen, I fell back on strace. Specifically, this call:

  strace  -xx  -e  trace=write  echo -e "\e[0Ksection_start:`date +%s`:name[collapsed=false]\r\e[0Kdescription" 2> /tmp/trace.txt
  

  The output from that was:

  write(1, "\x1b\x5b\x30\x4b\x73\x65\x63....

  The \x1b became the 27 in my program: the ascii escape character.

  With that, when I print output to the screen, the name portion is covered up and I only see the description. Since this is what happens with the bash code, I think I have something that will work on gitlab.

January 26, 2025

• Fedora Community Blog Fedora Operations Architect Report

  One more week of January to go, folks! And that also means we are one week closer to some key milestones coming up in the Fedora Linux 42 release. Here’s a summary of some release-related topics, plus some upcoming events and a general roundup of what’s happening around the project lately.

  Fedora Linux 42

  Fedora Linux 42 is currently in development, and for the most recent set of changes planned in this release, please refer to our change set page. Our release schedule is also live, and a reminder of some key dates are below:

  • All submission deadlines for system wide and self-contained changes have now passed. Please target F43 or later for any proposals you may have
  • February 4th – Changes need to be Testable
  • February 4th – Branching
  • February 18th – Changes need to be Complete
  • February 18th – Beta Freeze

  Fedora Linux 43

  From 4th February 2025, we will be in F43 development, so just in case you missed the deadlines for F42 change proposals, the good thing about Fedora releases is that there is always another, hot on the heels of the last – or at least it feels like that at times Please bookmark our schedule for some key dates for Changes, mass rebuild, branching, etc.

  Events

  FOSDEM 2025 returns on Saturday 1st and Sunday 2nd February in Brussels, Belgium. If you are attending and want to connect with some folks from around the Fedora Project, you can add your name to the Fedora @ FOSDEM wiki page.

  CentOS Connect also returns to Brussels on 30th and 31st January 2025. For more information and to register for the event, check out the event page.

  KubeCon and CloudNativeCon Europe is coming up in London, United Kingdom from April 1st – 4th, and registration is still open to attend.

  Open Source Summit North America cfp is open until February 17th, so don’t delay if you want to submit your talk idea(s) to attend this years event in Denver, Colorado on June 23rd – 25th.

  Devconf.cz call for papers is open! The event will take place in Brno, Czechia on June 12th – 14th 2025. Be sure to visit their event website for more information on talk themes, tracks and general stuff about the conference.

  Flock to Fedora has been announced! We hope to see you in Prague, Czechia from June 5th – 8th to celebrate our wonderful contributors. You can read more details about the event, and navigate to our cfp site from the Fedora Magazine article. Here is my 2c for submitting a talk or workshop to our cfp: The themes in our call for papers should be used as a guide for your talk or workshop. Be open-minded and flexible when matching your talk to a theme. The themes are not concrete, and so a well written paper that cleverly incorporates the heart or spirit of a theme is very valuable and appropriate to submit. The call for papers will close on February 23rd 2025, and I encourage you to make use of the flock-staff@fedoraproject.org email if you need some support with your talk or workshop submission.

  Hot Topics

  We have another datacentre move planned for Fedora this year, because we were excellent at the last one I joke, there are very good business reasons for the move and if you would like to read more about it, please visit the blog post on the proposed move dates and what it may mean for you.

  Boot-c in Fedora has another great weekly recap of their work. The new post is live on discussion.fpo now for you to enjoy.

  Be sure to check out the discussion section of discussion.fpo. It has lots of interesting topics and discussions happening.

  Notice Board

  There is an outage planned for necessary updates and reboots on 29th January. Please read this important email for more details on start time & duration for your awareness.

  Please review this list of packages that failed to build from source from our mass rebuild, and will be retired in F42 so that you are aware in case any of these packages impact you.

  Help Wanted! There is a fresh list of packages that have been orphaned and are looking for new maintainers. Please take a look at the list in gotmax23’s email and take a package or three if you have the desire and capacity

  The Fedora Google Summer of Code cfp for papers and mentors has officially opened. There is a great blog post about the program and process written by ffmancera, so do check it out if this is something you would like to get involved in. And as its one of the main Fedora Strategy goals – everyone has a mentor, everyone is a mentor – this is a great opportunity to help the project move closer to achieving this.

  There is a git forge open meeting happening every Wednesday on Matrix in #fedora-meeting @ 1400 UTC. You can import the calendar entry from fedocal from the fedora-release calendar. If you have interest in the projects move to Forgejo as our git platform, and want to help shape the deployment, development and migration, this is the venue to be in every week.

  Media Things

  Do you have an idea for an episode of the Fedora Podcast, or want to see what some of the upcoming episodes will be? Bookmark The IT Guy’s discussion post on planning for the podcast!

  Missed some of Fedoras recent release watch parties, or want to recap what talks happened at Flock to Fedora 2024? Never fear – all talks are now available on the Fedora Youtube Channel in the ‘latest’ video tab. Happy Streaming!

  Our Fedora Marketing team does amazing work promoting our distribution and all its cool spins and environments. If you would like to help out, volunteers are always welcome. You can join their matrix chat room, #Fedora Marketing and find out more about the kind of work they do from their docs page.

  The post Fedora Operations Architect Report appeared first on Fedora Community Blog.

• Frank Ch. Eigler some reasons you might want to buy a tesla

  Maybe you are ...

  ---

  ... someone who just likes to drive

  A Tesla is stupid fun to drive, if you treat it as if were just a normal car. The electric motor(s) have high torque for acceleration, and the machine features precise steering, and smooth tracking. For some models, the suspension is a little stiff, but that's normal for high-performance cars. It's easy to manoeuvre the thing exactly the way you want to. The audio system is great, and you don't even have to pump up to volume to enjoy it. They look pretty sharp. Recharging and winter are fine. Fun!

  ---

  ... keen on the environment

  A decade ago, one major selling point of electric vehicles was that they are purportedly good for the environment. Yeah, it's nowhere that simple, and should never be mandated, but whatever. They don't burn gasoline, so don't make that kind of mess. It's possible to get severe battery fires happening, but with a Tesla that seems require a catastrophic crash. So don't crash! But how?

  ---

  ... keen on safety ... someone who doesn't like to drive

  Got you, fam. Safety is the defining feature that sets Tesla apart from practically all other vehicles. Their way to get there is full automation, to the point where the car literally drives itself. Today's top implementation is called "Full Self Driving (Supervised)", and it feels pretty close. It can already take me door-to-door from this city to another one, including on city streets, traffic, highways, with zero or almost zero input. The driver just needs to "supervise", i.e., look outside and confirm the car is reading his mind properly. (If the car's about to make a mistake, the driver can instantly take over with a touch on the pedals or the steering wheel.)

  What makes this possible is a bunch of AI hardware and software in the car, fed by eight or so cameras that are looking in every direction. The hardware recognizes objects and positions; the software infers velocities, vulnerabilities, intent, and decides on driving control inputs. It needs all those cameras to build up a complete-enough view of the world to track lanes, safely do turns, lane changes, passing. The system draws a live 3D map of the surroundings of the car, including all other visible nearby vehicles, people, obstacles.

  What this also makes possible is to exceed the capacity of a human being to pay attention. The car is literally looking in every direction, and constantly, so it can respond to impending trouble in places where the human would not be looking. There are lots of crash-evasion videos out there, where the robot makes a rapid turn or brake to avoid hitting something that came out of the blue. The rear view cameras watch for bikers and pause your door opening if one is nearby, to protect them from "door prizes". It does not get tired, so even on a boring highway or with a sleepy driver, the thing stays solid.

  The FSD system is tied to the navigation software, so it knows where you want to go. A destination that you are unfamiliar with is not a problem. I recently had FSD drive in a foreign city, at night, where if I were driving by gps/map alone, it would have been a challenge. Constantly cross-checking street names, distances, GPS guidance with driving in an unknown city is super stressful. FSD is confident, knows where it's going, and turns the driver's job into just confirming tactical safety. So much easier!

  Another way to describe the feeling of supervising FSD will resonate with aviators. Supervising FSD feels just like flying with the autopilot engaged. A pilot can dismiss second-by-second minutiae, and switch to a strategic level of executive thinking. On the plane, with the autopilot on, one doesn't need to worry "am I centered in this airway? holding altitude?". Normally, the answer will be "yes". Similarly, with FSD, the driver can stop thinking "how exactly can we pass this guy?", and instead consider "how many minutes until the next turn? how is the battery usage compared to predictions? is there a washroom at the supercharger?". It's soothing. It makes long drives feel short.

  Yes, FSD is not perfect, though the monthly updates improve it constantly. Crashes can/do still occur, with or without FSD in control of the car. Tesla engineers wrapped the cabin in enough airbags and steel to protect people inside from normal crashes - and not just the cybertruck. It is unfortunately possible to manually race a Tesla like a drunken madman into concrete pillars, beyond the capacity of any car to protect the passengers, but so it goes.

  It feels like full self-driving - without supervision - is pretty close. That way, even people who grew too old to drive, or those who can't or don't want to own a Tesla, will be able to ride. This may take out the worst aspects of taxicab industries, and maybe parts of public transit.

  ---

  ... keen on comfort

  The Tesla hardware + software systems are designed to keep people comfy. During driving, the car is pretty quiet, with only tire and wind noise getting in. The electric motors are silent, and there is no engine + exhaust to rumble. You can talk quietly inside. Even the smallest model 3 is spacious, and the larger ones really feel large on the inside.

  The heating/cooling system is amazing. It conspires to scavenge excess heat from wherever in the entire car it may be generated or found, and send it to wherever it is needed. It's controllable remotely and by automated schedule, so the car can heat or cool or completely defrost its windows without anyone being there. There's no engine, so no fumes: this process can safely run anywhere - a parking lot or indoors. When you arrive at the car, it's ready and cozy. No more squirming in cold/hot seats for the first 15 minutes. Excellent air filtration - driving beside a landfill site is hard to notice.

  There's no fuel, so there's no need to stand outdoors to refuel. (Road-trip recharging is often outdoors, but you don't have to babysit the wire connection. You can just sit inside or visit a fast food joint and relax.) If you need to park somewhere strange, the car will auto-lock when you walk away, can keep an eye out around itself as a security camera while you're away, and (in a parking lot) can drive itself to you when you're ready to go.

  ---

  ... someone who likes to play with tech

  The car's main user interface is a big touchscreen, running some OS, maybe Linux, exposing all the systems in the car. There is also voice control, as in: "navigate to a gas station". Just kidding! The visualizations on the screen include a birds-eye view of the car and its surroundings, as detected by the AI system from all the cameras. Rear view cameras pop up when changing lanes. Interactive mapping is the default app to take up the bulk of the screen, but there are other options too. Several phone-app type gadgets are available. Several games(!) also, for use while the car is parked. Tesla likes expressing humour, so there are toy programs that play with the lights, make fart sounds, change the surroundings-visualization to a rendering of mars, or of Santa, a sketchpad to make blobfish-shaped-dad-portraits, that kind of silly stuff.

  The navigation software is pretty important, because it is tied into the battery management system. The car knows precisely how much charge it has, and when you tell it where you're going, it can integrate wind, temperature, traffic, topography, and maybe other factors, to estimate how much energy it'll take to get to your destination. If the battery is too low, it'll offer detours to en-route supercharger stations, and will tell you how long you'll need to charge for. (Often it's 5-15 minutes.) If you don't like the built-in navigation package, third-party phone apps with more routing/charging flexibility can be authorized to exchange telemetry with the car.

  If you want to know how the car works and how to work on it, you can read the entire service manuals. I hope you like software updates: every couple of weeks, new versions and features flow down, sometimes big improvements, sometimes small ones, and occasionally some regressions. The car literally improves with age.

  But if you're a weirdo who doesn't want to play with the tech, you can just take the car's navigation advice, use voice commands for everything, plug it in at home every night, and ignore the screen.

  ---

  ... someone who can put up with a little bit of big brother

  Tesla cars are perpetually Internet-connected via a built-in cellular data connection. This enables various remote control functions, clever navigation, software updates, and other things. In the case of a crash, I heard the car attempts to upload to the mothership a black-box worth of info about the last few seconds. At your option, you can volunteer to supply Tesla with much more data, via the cameras outside and inside the car. Basically, when something happens that surprises the AI system, a brief recording is uploaded to the mothership. This is used to train the next version of the AI system. In turn, everyone will receive the updated AI system before long. Unfortunately, this trust was violated a couple of years ago. We are assured discipline has improved, and again it's opt-in (and opt-out anytime).

  ---

  ... someone who can afford them

  Unfortunately, they are not yet cheap. A Tesla is priced similarly to high-end hybrids, well above entry-level sedans. On the other hand, operating costs are hilariously small. I've calculated that, compared to our Toyota RAV4 Hybrid (an amazingly fuel efficient SUV, with an 18-month wait to deliver), taking the Tesla for a similar ride costs about 10%, when recharged at home overnight! It's practically free for commuting. Also, there's basically no regular maintenance, as the most mechanical systems from a normal car just don't exist. At the end of every quarter and especially at the end of the year, some serious purchase discounts are normally available. Plus, any current Tesla owner can give you a referral link, from which you can get an additional $1-2K off the price (and they get some freebies too). Plenty of older used ones can be found, which can still run modern FSD AI.

  ---

  in conclusion:

  So yeah, the Tesla is not quite for everyone. But in case it might be for you, I'd love to show you ours - drop me an email. If you decide you want one, you can order it entirely online, in a few minutes, just like on Amazon. One could be in your garage literally in days. (We picked up our "custom" Model Y, just 4 days after a Sunday order.)

• Fedora fans معرفی Lazydocker – ابزار مدیریت ساده و کارآمد برای Docker

  

  Lazydocker یک ابزار رایگان و متن‌باز است که برای مدیریت و نظارت بر داکر (Docker) و داکر کامپوز (Docker Compose) از طریق یک رابط کاربری ترمینال بسیار کاربرپسند طراحی شده است. این ابزار به شما کمک می‌کند تا بدون نیاز به اجرای دستورات پیچیده، به راحتی کانتینرها، ایمیج‌ها، ولوم‌ها و سرویس‌های خود را مدیریت کنید. […]

  The post معرفی Lazydocker – ابزار مدیریت ساده و کارآمد برای Docker first appeared on طرفداران فدورا.

January 25, 2025

• Kevin Fenzi Bits from mid late jan 2025

  

  Hello again everyone! Three weeks in a row now. Go me. I'm not really sure what to name these posts, especially given that 'early/mid/late' does not work when there's 4 weeks in a month. I could just put the dates in the title, but that seems difficult to see what is going on. Perhaps I just need to pick out some highlights.

  mass rebuild completed

  The f42 mass rebuild was completed. This time submitting from the mass rebuild script seemed slower than normal. Possibly due to the item scaper item below. However, things mostly worked out. Instead of submitting everything and koji churning through the backlog, submissions were usually just handled as they came in, leaving koji with really no backlog.

  A.I. Scrapers

  The A.I. scrapers continue to pound away at things. I mean, I'm assuming thats what they are as they crawl all the content they can get. They are pretty hard to block due to using massive piles of IP's, different user agent strings every time and random access of content. This sort of thing is hitting lots of open source communities too. I think short time we probibly need to look at deploying mod_qos at least, so we can prioritize users/things that need access and let the scrapers get much lower levels of request answering. No idea if that will really stop them though.

  Anoying outage on thursday

  We had a very anoying outage on thursday. Our rabbitmq cluster started not processing things sometimes and just in general not working right. Restarting it and then a bunch of consumers that connect to it finally got things working again, but it's unclear what the cause was, and cleaning up a bunch of builds and such that were not processed due to missing messages was not at all fun. Currently our rabbitmq cluster is on rhel8 and an older version, we probibly want to move it to 9 and start using the version made by the CentOS messaging sig. If newer/older can talk to each other in a cluster it should be pretty easy. If they can't it will need some downtime.

  Mass update/reboot next week

  As we do from time to time, there's going to be a mass update/reboot cycle next week. Monday will be staging, then tuesday will be a bunch of things that don't cause any outages (where we can take things out and update/reboot and put them back in), and finally wed will have the actual outage.

  riscv secondary koji hub progress

  The riscv hub is installed and mostly configured, still need to sort out a few packages it needs to complete the ansible playbook. Next I need to test web interface, then install some x86 builders (that will do newrepos) and a compose host (for composes). Then will come the hard work of importing content / setting up actual riscv builders (which will be external for now until we can find hardware to use locally).

  Datacenter move

  We announced that we are going to be moving from our main datacenter (IAD2 in ashburn, va) to a new one (RDU3 in Raleigh, NC). It's going to be a ton of work (and lots has already happened, been spending a lot of time on it already), but when it's done we should be in a much better place. More space, better machines, and hopefully things like ipv6 support (that we have wanted for many years).

  comments? additions? reactions?

  As always, comment on mastodon: https://fosstodon.org/@nirik/113891021464841039

January 24, 2025

• Dan Horák Proposed changes for Fedora 42 affecting ppc64le

  Fedora is using so called Changes process
  for discussing, approving, coordinating and implementing important updates to the distro.
  It should be used for intrusive and user visible changes. For Fedora 42 there are 2 Changes proposed
  
• Stop building Atomic Desktops for PPC64LE and
  
• Stop building Flatpaks for PPC64LE
  that, when approved, can affect users of Fedora on ppc64le based systems.
  Although per the proposals there might be no users of those "Atomic" flavours of Fedora, so no one should be affected. But in case you are a Silverblue or Kinoite user
  or you use flatpaks on a ppc64le system, please let us know, ideally in the discussion threads opened for these changes.

• Lubomír Sedlář A compose what?

  Kushal wrote a nice post about how package updates get into repositories. However he glosses over rawhide by saying it happens automatically. This is true, but I want to elaborate on the mechanism of how it happens..

  A package build for Rawhide is not available in the repositories immediately. It has to wait until a nightly Rawhide compose runs that updates the repo.

  Let’s take a dive into what exactly the compose does and is.

  Terminology

  A compose is a snapshot of a release with a specific identity (which is determined by the actual release and date when it was created, like Fedora-Rawhide-20170710.n.0). It consists of at least one variant (such as Server, Workstation or Everything). A variant is a subset of the content from a release that is aimed for particular use case.

  Generally a variant in the final compose contains a repo with RPMs and other artefacts like images of various kinds.

  The compose is created by a tool called Pungi. Current major version 4 is significantly different to previous version in that it integrates with Koji and delegates as much work as possible to it (for better tracking and reproducibility).

  The main input for Pungi is a configuration file that can get quite complicated, due to all the extra artifacts like images. I’m only going to focus on the most common use case here.

  Getting the packages

  The process for defining what packages will go into the compose actually consists of two steps. First we need to find out the latest builds in Koji and find appropriately signed copies of the packages on the local file system (we need to have the same volume that Koji uses mounted locally).

  For nightly composes of Rawhide or branched the appropriate f2X tag is used. In milestone composes (where packages with freeze exception or fixes for accepted blockers are supposed to get in), there’s a special f2X-compose tag that inherits from f2X and this way other packages can get into the compose.

  $ koji list-tag-inheritance f26-compose
  f26-compose (368)
    └─f26 (357)

  The second step is to determine which packages are supposed to go into each variant. Each variant defines a list of comps groups. Packages from those groups will be pulled in together with all of their dependencies. This process needs to run once for each architecture on each variant.

  There are of course exceptions here: additional packages not in comps can be pulled in, and also there are configuration options to customize multilib rules and tweak other things.

  Creating repositories

  Once we have the package lists, we can call createrepo_c and create the actual metadata. The list of packages is actually part of the metadata in the final compose. Usually it’s a really big file located in compose/metadata/rpms.json (which is way too big to link here, but you can read description of the format).

  Building images

  There are multiple different images that can be built as part of the compose. Most work starts by calling lorax to create boot.iso and boot configuration files. This image is directly used as the netinstall media.

  Pungi can then create DVD images that include the repository. In Fedora this is currently only used for Server variant. This is done by basically taking the boot.iso and adding additional stuff to it.

  Spins and Labs are created in Koji using livemedia-creator (a livemedia task). This takes additional input of a kickstart file defining how that particular image should be created. The packages that are installed are taken from the repos created in the compose.

  How is it triggered?

  The nightly compose is started by a cron job that clones the latest configuration, runs the compose, and if it finishes successfully, it syncs the content to mirrors and sends e-mails about changes in packages.

  Branched composes have the same nightly process. Milestone composes are created in a similar way, but are started manually (because they require label via a command line argument).

  Conclusion

  That concludes the high level overview. The official documentation will go into a bit more detail once Pungi 4.1.17 is released.

• Lubomír Sedlář Today I Learned: Searching in Vim

  Ok, I lied. Searching in Vim is something I do all the time, so it’s not such a new thing. However there is a feature that I only need every once in a while, and always forget how to do it.

  The goal is to highlight something in the code, you can just search for it and if hlsearch is on, it will shine with the light of thousand suns.

  But what if you need some context to match the snippet, but only want to highlight part of the match?

  Search no more. The magic is done by including \zs or \ze in the search pattern. These snippets do not affect what is matched, but they set the start and end of the match respectively.

• Lubomír Sedlář Today I Learned: Handling source tarballs

  Fedora packages are generally built from tarballs provided by upstream developers. What’s actually happening to these tarballs and how do they move around?

  How are sources uploaded?

  When a new tarball is supposed to be used, the packager will upload it to lookaside cache (because storing big binary files directly in git is bad). This is done with fedpkg upload or fedpkg new-sources. These commands make a POST request to a CGI script running on the dist-git server. This requests includes the name of the file, a checksum and the actual file contents.

  Up until today (Dec 12) MD5 hash has been used. Now it’s SHA512.

  There are actually two requests each time an upload is requested: the first one is to check if a file with the same name and hash has been uploaded already. If it is, there’s no point doing it again.

  How does fedpkg download them?

  Downloading back to development machine is done by fedpkg sources. It reads the sources file in the git repository and requests the files from lookaside cache. The URL for the files contains both filename and the hash.

  Once the file is downloaded, the hash is verified to make sure we got the file we asked for.

  How does Koji download them?

  When a build is submitted to Koji, an SCM URL has to be specified. It needs to point to commit you want to build. Koji will not allow you to build from arbitrary locations though. There is a whitelist of allowed systems.

  Once the spec and list of sources are downloaded, the actual source code needs to be retrieved as well. Unless configuration specifies otherwise, Koji would run make sources. For Fedora dist-git, the command is unsurprisingly configured to be fedpkg sources.

  However, since this command needs to run the buildroot and fedpkg has a relatively big dependency footprint, the fedpkg command in buildroots is provided by fedpkg-minimal package. This package contains a single executable shell script that parses the sources file, downloads everything and verifies the hashes.

• Lubomír Sedlář Clickable Pungi logs

  When debugging problems with composes, the logs left behind by all stages of the compose run are tremendously helpful. However, they are rather difficult to read due to the sheer volume. Being exposed to them quite intensively for close to a year helps, but it still is a nasty chore.

  The most accessible way to look at the logs is via a web browser on kojipkgs. It’s just httpd displaying the raw log files on the disk.

  It took me too long to figure out this could be made much more pleasant that copy-pasting stuff from the wall of text.

  How about a user script that would run in Greasemonkey and allow clicking through to different log files or even Koji tasks?

  

  Turns out it’s not that difficult.

  Did you know that when Firefox displays a text/plain file, it internally creates an HTML document with all the content in one <pre> tag.

  The whole script essentially just runs a search and replace operation on the whole page. We can have a bunch of functions that take the whole content as text and return it slightly modified.

  First step will make URLs clickable.

  function link_urls(str) {
    let pat = /https?:\/\/(www\.)?[-a-zA-Z0-9@:%._\+~#=]{2,256}\.[a-z]{2,6}\b([-a-zA-Z0-9@:%_\+.~#?&//=]*)/g;
    return str.replace(pat, '<a href="$&">$&</a>');
  }

  I didn’t write the crazy regular expression myself. I got from Stack Overflow.

  Next step can make paths to other files in the same compose clickable.

  function link_local_files(url, pathname, mount, str) {
    let pat = new RegExp(mount + pathname + '(/[^ ,"\n]+)', 'g');
    return str.replace(pat, function (path, file) {
      return '<a href="' + url + file + '">' + path + '</a>';
    });
  }

  The last thing left is not particularly general: linking Koji tasks identifiers.

  function link_tasks(taskinfo, str) {
    return str.replace('\d{8,}/m', '<a href="' + taskinfo + '$&">$&</a>')
              .replace(/(Runroot task failed|'task_id'): (\d{8,})/g,
                       '$1: <a href="' + taskinfo + '$2">$2</a>');
    }
  }

  Tying all these steps together and passing in the extra arguments is rather trivial but not very generic.

  window.onload = function () {
    let origin = window.location.origin;
    let pathname = window.location.pathname.split('/', 4).join('/');
    let url = origin + pathname;
    let taskinfo = 'https://koji.fedoraproject.org/koji/taskinfo?taskID=';
    let mount = '/mnt/koji';
  
    var content = document.getElementsByTagName('pre')[0];
    var text = content.innerHTML;
    content.innerHTML = link_local_files(
      url, pathname, mount,
      link_tasks(taskinfo, link_urls(text))
    );
  }

  If you find this useful, feel free to grab the whole script with a header.

• Lubomír Sedlář Introducing entr

  When writing code, my workflow is usually to make edits and re-run the test suite (that is, if there is one). This is actually a lot of work that I don’t want to do.

  Thankfully, it’s quite easy to automate. All we need is a utility that would watch files for change and then run the tests.

  On Linux, we can somewhat get by with inotifywait, but it is rather tedious. There must be a better way; and there actually is.

  Well, the future is here and its name is entr. It runs arbitrary commands when files change. The list of files to monitor is provided on standard input.

  It turned out that I most often want to watch all relevant files in current directory. Therefore, I created a small wrapper that will find all interesting files in current directory and pass them to entr. I call it guard.

  #!/bin/sh
  set -o pipefail
  ag -g '' | entr "$@"

  Using git ls-files would work almost as well as the silver searcher. Using find would work as well if you’re inclined that way.

  Go get it!

  If you want to try it out and automate your workflow a bit, there is now a Fedora package, currently in waiting in Bodhi to be pushed stable (for F23, F24, F25 and EPEL 7). Feel free to get it from updates-testing repository.

  $ sudo dnf install entr --enablerepo=updates-testing

  Many thanks to Igor Gnatenko for review and packaging suggestions.

• Felipe Borges Time to write proposals for GSoC 2025 with GNOME!

  It is that time of the year again when we start gathering ideas and mentors for Google Summer Code.

  @Mentors, please submit new proposals in our Project ideas GitLab repository before the end of January.

  Proposals will be reviewed by the GNOME GSoC Admins and posted in https://gsoc.gnome.org/2025 when approved.

  If you have any doubts, please don’t hesitate to contact the GNOME Internship Committee.

• Fedora Community Blog Infra and RelEng Update – Week 04 2025

  This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. 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: 20th January – 24th January 2025

  

  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:
    • Please generate the Fedora 44 gpg key
    • Opt-in for AWS region to mx-central-1 acct:125523088429
    • Opt-in for AWS region to ap-southeast-7 acct:125523088429
    • retire easyfix
    • bvmhost-p09-03 ends in emergency mode
    • Add StartInstanceRefresh permission for fedora-ci-testing-farm user in AWS
    • distgit-bugzilla-sync poddlers in both staging and prod downloading a lot from production
    • Deploy Element Server Suite operator in staging
    • Create CentOS calendar
    • Pagure returns error 500 trying to open a PR on https://src.fedoraproject.org/rpms/python-setuptools-gettext
    • Inactive packagers policy for the F41 release cycle
    • a real domain name for konflux
    • Retirement of `monitor-dashboard` tracker
    • Create a POC integration in Konflux for fedora-infra/webhook-to-fedora-messaging
    • Retirement of `monitor-gating` tracker
    • setup ipa02.stg and ipa03.stg again as replicas
    • Manage our new testing.farm domain via AWS Route53
    • Add support for creating RDS instances under `testing-farm-` prefix
    • Move OpenShift apps from deploymentconfig to deployment
    • RFE: fedoras container image register change
    • The process to update the OpenH264 repos is broken
    • httpd 2.4.61 causing issue in fedora infrastructure
    • Support allocation dedicated hosts for Testing Farm
    • fedorapeople.org directory listing theme needs refreshing
    • EPEL minor version archive repos in MirrorManager
    • vmhost-x86-copr01.rdu-cc.fedoraproject.org DOWN
    • Add yselkowitz to list to notify when ELN builds fail
    • Cleaning script for communishift
    • rhel7 eol
    • move resultsdb-ci-listener deployment pipeline
    • rhel7 EOL – github2fedmsg
    • Move from iptables to firewalld
    • Help me move my discourse bots to production?
    • fedmsg -> fedora-messaging migration tracker
    • rhel9 adoption
    • Create monitoring tool for rabbitmq certificates
    • Replace Nagios with Zabbix in Fedora Infrastructure
    • Migration of registry.fedoraproject.org to quay.io
    • Commits don’t end up on the scm-commits list
  • Done:
    • Move personal GitHub repository to fedora-infra org
    • extra trailing slash on epel.io redirect breaks page rendering
    • Messed up rpm/valgrind pull request/branch
    • New Issue information page broken link
    • bastion delivering locally to non contributor accounts
    • mirrorlist is returning too few mirrors
    • New requirements for Google and Yahoo mail at least

  CentOS Infra including CentOS CI

  • In progress:
    • [spike] : investigating options/alternatives for the upcoming DC move
    • Zuul CI namespace
    • Setup hyperscale-kernel tag for c10s
    • Testing Jenkins – c10s x86_64 metal doesn’t provision
    • Release Improvements
  • Done:
    • Add DNS record for Bluesky
    • Upgrade our various OCP clusters to latest version from 4.15.x branch
    • More powerful aarch64 instance on duffy
    • New mirror request: mirror.i3d.net
    • Investigate Koji draft builds

  Release Engineering

  • In progress:
    • Unretire tachyon
    • Unretire ethos
    • Quay.io repository for fedora-bootc-tier-x
    • Missing rawhide branch for recently created package ‘pybind11-json’
    • F42 Self-Contained Change: Switch to EROFS for Live Media
    • Please remove two branches from octave-iso2mesh
    • Send compose reports to a to-be-created separate ML
    • .sqlite metadata missing in f41-updates and f41-updates-testing repositories
    • F42 system-wide change: GNU Toolchain update for F42 https://fedoraproject.org/wiki/Changes/GNUToolchainF42
    • Delete “firefox-fix” branch in xdg-desktop-portal
    • please create epel10 based el10-openjdk tag
    • Could we have fedoraproject-updates-archive.fedoraproject.org for Rawhide?
    • Investigate and untag packages that failed gating but were merged in via mass rebuild
    • a few mass rebuild bumps failed to git push – script should retry or error
    • Renaming distribution media for Fedora Server
    • Package retirements are broken in rawhide
    • Implement checks on package retirements
    • Untag containers-common-0.57.1-6.fc40
    • orphan-all-packages.py should remove bugzilla_contact entries from fedora-scm-requests as well
    • Packages that fail to build SRPM are not reported during the mass rebuild bugzillas
    • When orphaning packages, keep the original owner as co-maintainer
    • Create an ansible playbook to do the mass-branching
    • RFE: Integration of Anitya to Packager Workflow
    • Cleaning old stuff from koji composes directories
    • Fix tokens for ftbfs_weekly_reminder. script
    • Update bootloader components assignee to “Bootloader Engineering Team”for Improved collaboration
  • Done:
    • Stalled EPEL package: python-zope-exceptions
    • Stalled EPEL package: python-pytest-subtests
    • F42 Self-Contained Change: Promote KDE Plasma Desktop variant to Edition
    • The build `localsearch-3.8~rc-1.fc42` is in `DELETED` state and is blocking me from rebuilding
    • Failed request-repo action for sgx-rpm-macros
    • Unretire virt-who
    • latest-Fedora-Cloud-41 directory missing on the cloud compose listing

  If you have any questions or feedback, please respond to this report or contact us on #redhat-cpe channel on matrix.

  The post Infra and RelEng Update – Week 04 2025 appeared first on Fedora Community Blog.

January 23, 2025

• Rajeesh K Nambiar International Calligraphy Festival of Kerala 2024

  The third International Calligraphy Festival of Kerala (ICFK) took place in October 2024, and I was invited to run a session. I had the fortune to see many exemplary calligraphers all over the world come together and demonstrate their work over three days of the festival.

  Renowned Malayalam calligrapher Narayana Bhattathiri organizes the conference every year, and it was amazing to witness that many of the speakers and calligraphers were sharing the responsibilities and taking active role in the organization and execution of the sessions. The audience and speaker participation and interactions were warmly welcoming. The demographics was very distributed — students, professionals, calligraphers; and of all ages and genders.

  An epiphany

  During the session by Prof. G.V. Sreekumar when he asked the participants to write the word ‘സൂര്യൻ’ (the Sun); I took a survey of the writings. What I found was that the older generation all wrote the word in traditional Malayalam orthography; and a large number of younger generation also wrote it in traditional orthography. The latter group were not taught in schools to read or write in traditional script (the text books are all in broken/reformed script). Intrigued how they were familiarized with the traditional orthography, I had questioned how they knew to write in this fashion. The answers were categorized into:

  1. They saw their parents write in traditional orthography.
  2. They saw their grandparents write in traditional orthography (but their parents write in reformed script).
  3. Most strikingly, some youngsters were sure this was the ‘correct’ way of writing and yet they could not explain how or from where they learnt it.

  The response from the third category is very interesting: because they learnt the script ‘organically’ and it is imbibed in their identity — which is what the definition of ‘culture’ is. The revelation is that; the script belongs to its people and no matter what the government decrees about (ref: Kerala govt orders about script reform in 1971 and 2022).

  The session

  Together with type designer Athul Jayaraman, I had a joint session on typography. Athul focused more on the type design and I had elaborated more on Malayalam script (traditional orthography), and font engineering & techniques.

  The Mathrubhumi news team also interviewed both of us and published a two-part series of the interview on their new site:

  • Part 1 of the interview.
  • Part 2 of the interview.

  The experience

  Of the many conferences I have been to, ICFK 2024 was one the best un-conferences in my experience. I met a lot of exemplary, yet humble & approachable, calligraphers (some of them gave me their autographed booklets, thank you!), learnt a lot and enjoyed thoroughly.

  

• Ken Dreyer returning to Red Hat

  Last week I accepted an offer to work at Red Hat in the InstructLab engineering team. I can't wait to join this company again.
  

  

  
  

January 21, 2025

• Peter Czanik syslog-ng OSE 4.8.1 is now in EPEL 10, quick fix for Elasticsearch

  This blog is just a quick announcement that syslog-ng 4.8.1 is now available in EPEL 10, so you do not have to use the testing repository anymore. Thanks everyone for the feedback!

  However, support for Elasticsearch 7+ is broken in this release, as some of you reported. You can fix this problem as described in https://github.com/syslog-ng/syslog-ng/issues/5207 by removing references to “type”. Note that this fix removes compatibility with Elasticsearch 6.x, but if you are installing a beta RHEL release or compatible operating system, then you most likely do not use an Elasticsearch version anyway that has long reached its end-of-life… :-)

  That said, if you still use Elasticsearch 6.x, then everything should keep working as is. For version 7.x or later, here is the quick fix. Normally, you should not edit files under /usr/share/syslog-ng/include/scl/ yourself. However, in this case, the problem can be fixed by editing /usr/share/syslog-ng/include/scl/elasticsearch/elastic-http.conf and removing references to “type” from two places.

  The first is from the block, where we define it with an empty string parameter:

    type("")

  The second location is from the body() template:

  index._type=`type`

  This solves the immediate Elasticsearch problem, but a proper fix will be part of the 4.8.2 release. There, the “real” solution will be fixing the --omit-empty-values parameter of the format-json() template function.

  -

  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.

January 20, 2025

• Luca Ciavatta Linux Unveiled. The Silent Giant Powering Our Digital World

  

  Introduction: Beyond the Desktop

  When most people think about operating systems, Windows and macOS typically come to mind. However, Linux — a free, open-source operating system — has been quietly revolutionizing technology in ways most users never realize. Despite holding only 4.5% of the global desktop market, Linux is actually the backbone of our digital infrastructure.

  

  The Linux Landscape: More Than Meets the Eye

  Linux isn’t just an alternative operating system; it’s a global technological phenomenon that powers:

  • 71% of mobile devices (Android)
  • 96.4% of web servers
  • All 500 of the world’s fastest supercomputers
  • Majority of IoT and embedded systems

  What Makes Linux Extraordinary?

  Open Source: A Philosophical Revolution

  Unlike proprietary systems like Windows or macOS, Linux represents a radical approach to software development. It’s not just a product—it’s a collaborative, community-driven ecosystem that embodies principles of:

  • Transparency
  • Freedom
  • Customization
  • Security
  • Performance

  Linux Dominance: Where You Don’t See It

  Mobile Domination: Android’s Linux Heart

  Linux Unveiled: most smartphone users are unknowingly Linux users. Android, based on the Linux kernel, controls 71% of the global mobile operating system market. This means billions of people interact with Linux daily without realizing it.

  Link: https://www.android.com/

  Server Infrastructure: The Internet’s Backbone

  When you browse websites, stream videos, or use cloud services, you’re likely accessing Linux-powered servers. An astounding 96.4% of the top one million web servers run on Linux, making it the undisputed champion of server infrastructure.

  Link: https://truelist.co/blog/linux-statistics/

  Supercomputing: Computational Powerhouse

  Linux doesn’t just handle everyday computing—it powers scientific research, weather prediction, and complex simulations. All 500 of the world’s fastest supercomputers exclusively use Linux, highlighting its unparalleled performance and reliability.

  Link: https://top500.org/

  IoT and Embedded Systems: Linux Everywhere

  From smart TVs to internet routers, Linux’s lightweight and robust nature makes it the preferred choice for embedded systems. Estimates suggest that 71% of IoT devices run on Linux, demonstrating its versatility beyond traditional computing.

  Link: https://www.iotforall.com/linux-iot-landscape-distributions

  Why Isn’t Linux Dominating Desktops? Why?

  The User-Friendliness Challenge

  Despite its technical superiority, Linux faces significant barriers in desktop adoption:

  1. Complex installation processes
  2. Limited software compatibility
  3. Steeper learning curve
  4. Less intuitive user interfaces
  5. Hardware compatibility issues

  The Ecosystem Problem

  Most commercial software and games are designed for Windows, creating a significant barrier for potential Linux adopters. While improvements have been made with platforms like Steam’s Proton, compatibility remains a challenge.

  Link: https://store.steampowered.com/steamos

  The Philosophical Difference

  Linux can be compared to a fully customizable house, while Windows and macOS are more like apartments with strict rules. This fundamental difference attracts tech enthusiasts but intimidates average users.

  Link: https://itsfoss.com/tag/customization/

  Getting Started with Linux

  Beginner-Friendly Distributions

  For those interested in exploring Linux, several user-friendly distributions make the transition smoother:

  1. Ubuntu: Most popular, highly intuitive – https://ubuntu.com/
  2. Linux Mint: Windows-like interface – https://linuxmint.com/
  3. Elementary OS: macOS-inspired design – https://elementary.io/
  4. Pop!_OS: Great for developers and designers – https://pop.system76.com/
  5. Fedora: Cutting-edge technology – https://fedoraproject.org/

  Bonus: – what I actually use both on desktop and laptop – it’s openSUSE Linux, the makers’ choice for sysadmins, developers and desktop users.

  Link: https://www.opensuse.org/

  The Future of Linux

  Emerging Trends

  • Increased gaming support
  • Better hardware integration
  • More user-friendly interfaces
  • Enhanced software compatibility
  • Growing corporate adoption

  Conclusion: The Quiet Revolution

  Linux might not dominate desktop computing, but it’s the unsung hero of our digital world. It powers everything from smartphones to supercomputers, embodying principles of openness, collaboration, and innovation.

  Call to Action

  For tech enthusiasts, developers, and curious minds: please, try and explore Linux!

  Whether through a virtual machine, dual-boot setup, or dedicated installation, understanding Linux means understanding the past, the present and the future of computing.

  ---

  Sources:

  • Opensource | Linux Unveiled – https://opensource.com/
  • Linux Foundation Annual Reports – https://www.linuxfoundation.org/resources/publications/linux-foundation-annual-report-2024
  • Various open-source technology publications (links inside the article)

  The post Linux Unveiled. The Silent Giant Powering Our Digital World appeared first on CIALU.NET.

• Richard Hughes fwupd 2.0.4 and DBXUpdate-20241101

  I’ve just tagged fwupd 2.0.4 — with lots of nice new features, and most importantly with new protocol support to allow applying the latest dbx security update.

  The big change to the uefi-dbx plugin is the switch to an ISO date as a dbx version number for the Microsoft KEK.

  The original trick of ‘count the number of Microsoft-owned hashes‘ worked really well, just until Microsoft started removing hashes in the distributed signed dbx file. In 2023 we started ‘fixing up‘ the version based on the last-added checksum to make the device have an artificially lower version than in reality. This fails with the latest DBXUpdate-20241101 update, where frustratingly, more hashes were removed than added. We can’t allow fwupd to update to a version that’s lower than what we’ve got already, and it somewhat gave counting hashes idea the death blow.

  Instead of trying to map the hash into a low-integer version, we now use the last-listed hash in the EFI signature list to map directly to an ISO date, e.g. 20250117. We’re providing the mapping in a local quirk file so that the offline machine still shows something sensible, but are mainly relying on the remote metadata from the LVFS that’s always up to date. There’s even more detail in the plugin README for the curious.

  We also changed the update protocol from org.uefi.dbx to org.uefi.dbx2 to simplify the testing matrix — and because we never want version 371 upgrading to 20230314 automatically — as that would actually be a downgrade and difficult to explain.

  If we see lots of dbx updates going out with 2.0.4 in the next few hours I’ll also backport the new protocol into 1_9_X for the soon-to-be-released 1.9.27 too.

• Harish Pillay 9v1hp Wireless@SGx for Linux – 2025 update

  

  I am really pleased to see that the unsung heros at IMDA.gov.sg have finally provided information about how to connect to the Wireless@SGx network for the growing group of users who only use Linux as their primary operating system on their laptops.

  I’ve documented the trials and frustrations over the years about Wireless@SGx, and it is finally no longer something that we have to decipher, reverse engineer and break in order to use.

  For the longest time, we have to decode what the registration protocol was. All of this was very cleverly reverse engineered by zerotypic and published on github.

  I’ve been using that method to connect all of my laptops to the Wireless@SGx sites all these years.

  But, sometime in July 2024 (why, because the IMDA page says it was “Last Updated 01 AUG 2024”), something changed. There as a new method to connect to Wireless@SGx that was introduced.

  It provides information for those with a local SIM card for the usual devices and another method for non-SIM card devices like laptops, tablets etc.

  

  

  They could have said “Linux/Android/ChromeOS/Windows & Other Operating Systems”, but they did not. And since Android and ChromeOS are Linux anyway, I guess, if you know, you know.

  I hope this blog post will help nudge the folks at IMDA to update that site to state the obvious.

  Once you click on the “Setup Now” button, you would be presented with a T&Cs page and once that is acknowledged, the following screen, for a three-step process:

  

  Pick a provider, provide a DOB and a mobile phone number (ie, it can be anyone from anywhere), click on the “I agree to the terms and conditions” box (will only be clickable once you have picked a provider), answer the captcha and then click on the “Next” button.

  An SMS is sent with a 6 digit code which you need to enter following which the next screen, shown below, will contain the needed information to log into any Wireless@SGx location.

  Note: You can set this up ahead of time and not have to wait until you get to a Wireless@SGx location to setup.

  

  There are three bits of information that is provided: the username, the password and the “Provider’s Domain name“. The last one is something new and will be different for the different providers.

  For ease of use and future reference, here are the 4 Provider’s Domain names. I have no idea if the Provider’s Domain name will ever change, but if it does, please inform me or file an issue at the github page so that it can be updated.

  Provider Domain Names:

  Singtel	singtel-wsg.singtel.com
  M1	rinoa.m1net.com.sg
  SIMBA/TPG	tpgmobile.sg
  Starhub	uniaaa2.wifi.starhub.net.sg

  On my Fedora Linux 41system, I updated the Wireless settings dialog box:

  

  You would place the username into the “Anonymous identity” AND “Username” boxes, the Provider’s Domain name in the “Domain” box, and the password in the “Password” box.

  And that was all that was needed to be done.

  But we will keep the github project still alive in case there is a regression and disconnects Linux users.

  Why use Wireless@SGx?

  People have asked me why I would want to use Wireless@SGx given that the 5G network is widely available and the bundled data is enormous and that I can just turn on the wireless hotspot on my mobile to have the laptop to connect.

  Yes, that will work.

  But the Wireless@SGx is a service that offloads from the cellular network and therefore the Right Thing to do.

  In any case, I do have my mobile phone(s) and my laptop(s) connect to my wireguard end point (using a pivpn+pihole setup), so all traffic is always encrypted making the use of a public hotspot that Wireless@SGx is, just fine and not a security concern.

January 19, 2025

• Adam Young Reading envvars using plumbum

  One of my new years resolutions this year was to try and replace bash scripting with python in some of my projects. The reasons for this include the ability to use objects to group parameters together.
  
  At today’s (Jan 19, 2025) Python over Coffee meetup, Ricardo suggested that I look at the plumbum library as a tool to help make that transition. In my first hack at using it, I came across an issue: I need to read in environment variables.

  We store envvars in a file like this:

  
  
  export SOC_ID="soc04"
  export BASE_TAG="v6.12.1"
  export BRANCH_TAG="v6.12.1"
  TOPICS_ROOT="linux/6.12.y"
  NOTE='
  Long note
  explaining things.
  '

  These envvars then need to be passed to the files we execute. Since plumbum does not have the concept of sourcing a file the way that we would in bash, we have to read in the variables directly. Here is a hacky script for reading in the envvars:

  #!/bin/python3
  
  from plumbum import local
  
  
  CONF_FILE="config/gen-ac04-v6.12-general.conf"
  
  def main():
      val=""
      appending=False
      with open(CONF_FILE, 'r') as file:
          for line in file:
              if appending and line[-1] == "'":
                  appending=False
                  print("%s %s:" % (key, val))
              if ("export" in line):
                  line = line.replace('export ', '')
                  words = line.rstrip().split("=")
                  key=words[0]
                  if (words[1] == "'"):
                      appending=True
                      val=""
                      continue
                  elif appending:
                      val=val+ words[1]
  
                  else:
                      val=words[1]
                      print("%s %s:" % (key, val))
                      local.env[key]=val
      print ("Hello")
  
  
      for key, value in local.env.items():
          print("key = %s, value=%s" %(key, value))
  
  main()
  

  I am sure this could be cleaned up significantly, but we also can find a better way to share our environment variables.

  The real problem is that our bash scripting is done using functions, and without “source” we have no way to pull those in and execute the individual functions.”

January 18, 2025

• Kevin Fenzi Bits from mid jan 2025

  

  Hello again, here's some longer form doings and thoughts from from mid january 2025 in and around fedora.

  rawhide repodata change

  Rawhide repodata has moved over to the createrepo_c default: zstd. This shouldn't affect any dnf use, or fedora createrepo_c use, but if you are using EL8/EL9, createrepo_c there currently doesn't understand zstd. There's a issue to add that in a minor release: https://issues.redhat.com/browse/RHEL-67689 and in the mean time if you are a EL8/9 user there's a copr: https://copr.fedorainfracloud.org/coprs/amatej/createrepo_c/

  dist-repos retention

  On the dist-repos space issue I mentioned last week, it turns out that the expectation on dist-repos is that you would sync them somewhere you wanted to serve them from, not just serve from koji. So our use case was misalined a bit from upstream here. However, they did adjust to keep latest repos. Should be in a upcoming koji release. Thanks koji folks!

  fun email infrastructure mixup between ipa and postfix

  There was a pretty curious email issue that came up this last week. fedoraproject contributors (that is folks with an account that is in at least one non system group) are setup with an email alias of theiraccountlogin@fedoraproject.org. This is just a very simple alias. We accept the email and forward it to their real email address. There's no mailbox here or authentication or anything, just a simple alias. We got an alert that disk space was getting low on our mail hub, so I took a look and found that users who were not contributors were getting emails to theiraccountlogin@fedoraproject.org delivered locally to /var/spool/mail on the hub! When we switched away from fas2 to our current IPA based setup, no one realized that sssd/ipa enumerates all users, even if they do not have access to actually login or do anything. There are good reasons for this, but somehow I at least didn't realize that it worked that way. So, since all users 'existed' there, and postfix's default for local users is:

  proxy:unix:passwd.byname $alias_maps

  It correctly looks them up and thinks they are local. Simply changing this to just be $alias_maps fixes the issue. There wasn't a bug here in postfix or ipa, they were just doing things as they expected. The issue was our misunderstanding how these things interacted.

  f42 mass rebuild underway

  The mass rebuild for f42 started (all be it a bit later than planned due to a issue getting golang to work on i686 when compiled with gcc 15). This time it seems like our submitting builds is much slower than before. In past years, pretty much everything was submitted in a few days, then koji chewed on the backlog. This time koji is easily keeping up with the submissions and we are only in the 'p's after 3.5 days. Oh well, hopefully we will finish mondayish, which is in line with past mass rebuilds.

  forgejo kickoff meeting/discussions

  There was a kickoff meeting about forgejo in fedora infra. I'm looking forward to this, but I have so many things going on I am not sure how much work I can do on the deployment. Lots of good ideas/plans discussed. I think it's going to be not a super lot of work to stand up a staging instance, but I think integrating with all our workflows will take a lot more effort. Time will tell.

  riscv secondary koji hub

  I did finally submit my work in progress PR for riscv-koji hub: https://pagure.io/fedora-infra/ansible/pull-request/2435 Hopefully can finish off things and start deploying next week.

  bugzilla and needinfo

  I asked on mastodon what folks thought about bugzilla needinfo requests and what they meant. There were a number of opinions: https://fosstodon.org/@nirik/113822583672492457 I think in the end it's a thing that people will use for their own use cases and those will sometimes mis match with recipients. Unless we want to try and make some community wide norm or guidelines (but of course even then not everyone will see those).

  Xfce-4.20 and wayland testing

  News from a while ago: Xfce 4.20 was released and it's got a bunch of wayland support for various things. However, it doesn't have xfwm4 / a compositor of it's own, so by default you get a X session. If you want to play with the wayland sessions and you are running a rawhide instance, you can install: xfce4-session-wayland-session which will by default pull in labwc as your compositor. You can manually modify the session file to use wayfire if you prefer that compositor. See the testing section at https://wiki.xfce.org/releng/wayland_roadmap I tried both out and they did indeed work, but there are still a bunch of rough edges. Still, great progress!

  comments? additions? reactions?

  As always, comment on mastodon: https://fosstodon.org/@nirik/113850897869803740

• Kushal Das Dealing with egl_bad_alloc error for webkit

  I was trying out some Toga examples, and for the webview I kept getting the following error and a blank screen.

  Could not create EGL surfaceless context: EGL_BAD_ALLOC.
  

  After many hours of searching I reduced the reproducer to a simple Python Gtk code.

  import gi
  
  gi.require_version('Gtk', '3.0')
  gi.require_version('WebKit2', '4.0')
  
  from gi.repository import Gtk, WebKit2
  
  window = Gtk.Window()
  window.set_default_size(800, 600)
  window.connect("destroy", Gtk.main_quit)
  
  scrolled_window = Gtk.ScrolledWindow()
  webview = WebKit2.WebView()
  webview.load_uri("https://getfedora.org")
  scrolled_window.add(webview)
  
  window.add(scrolled_window)
  window.show_all()
  Gtk.main()
  

  Finally I asked for help in #fedora IRC channel, within seconds Khaytsus gave me the fix:

  WEBKIT_DISABLE_COMPOSITING_MODE=1 python g.py
  

  

January 17, 2025

• Remi Collet ⚙️ PHP version 8.3.16 and 8.4.3

  RPMs of PHP version 8.4.3 are available in the remi-modular repository for Fedora ≥ 39 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

  RPMs of PHP version 8.3.16 are available in the remi-modular repository for Fedora ≥ 39 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

  ℹ️ The packages are available for x86_64 and aarch64.

  ℹ️ There is no security fix this month, so no update for version 8.1.31 and version 8.2.27.

  ⚠️ PHP version 8.0 has reached its end of life and is no longer maintained by the PHP project.

  These versions are also available as Software Collections in the remi-safe repository.

  Version announcements:

  • PHP 8.4.3 Release Annoucement
  • PHP 8.3.16 Release Annoucement

  ℹ️ Installation: use the Configuration Wizard and choose your version and installation mode.

  Replacement of default PHP by version 8.4 installation (simplest):

  dnf module switch-to php:remi-8.4/common
  

  Parallel installation of version 8.4 as Software Collection

  yum install php84

  Replacement of default PHP by version 8.3 installation (simplest):

  dnf module switch-to php:remi-8.3/common
  

  Parallel installation of version 8.3 as Software Collection

  yum install php83

  And soon in the official updates:

  • Fedora Rawhide now has PHP version 8.4.3
  • Fedora 41 - PHP 8.3.16
  • Fedora 40 - PHP 8.3.16

  ⚠️ To be noticed :

  • EL-10 RPMs are built using RHEL-10.0-beta
  • EL-9 RPMs are built using RHEL-9.5
  • EL-8 RPMs are built using RHEL-8.10
  • intl extension now uses libicu74 (version 74.2)
  • mbstring extension (EL builds) now uses oniguruma5php (version 6.9.10, instead of the outdated system library)
  • oci8 extension now uses the RPM of Oracle Instant Client version 23.6 on x86_64, 19.25 on aarch64
  • a lot of extensions are also available, see the PHP extensions RPM status (from PECL and other sources) page

  ℹ️ Information:

  • Migrating from PHP 8.2.x to PHP 8.3.x
  • Migrating from PHP 8.3.x to PHP 8.4.x

  Base packages (php)

  

  

  Software Collections (php81 / php82 / php83)

  

  

January 16, 2025

• Peter Czanik The syslog-ng Insider 2025-01: Alpine Linux; Leap 16.0; Alma Linux

  Dear syslog-ng users,

  
  

  This is the 127th issue of syslog-ng Insider, a monthly newsletter that brings you syslog-ng-related news.

  NEWS

  A syslog-ng container image based on Alpine Linux

  Recently, someone suggested I should check out Alpine Linux and prepare a syslog-ng container image based on it. While not supported by the syslog-ng project, an Alpine-based syslog-ng container image already exist as part of the Linuxserver project.

  https://www.syslog-ng.com/community/b/blog/posts/a-syslog-ng-container-image-based-on-alpine-linux

  Call for testing: syslog-ng in openSUSE Leap 16.0

  Last week, I submitted syslog-ng to openSUSE Leap 16.0. While the distro is still in a pre-alpha stage, everything already works for me as expected. Well, except for syslog-ng, where I found a number of smaller problems. As such, this blog is a call for testing, both for syslog-ng on openSUSE Leap 16.0 and also for the distribution itself.https://www.syslog-ng.com/community/b/blog/posts/call-for-testing-syslog-ng-in-opensuse-leap-16-0

  Experimental syslog-ng container image based on Alma Linux

  The official syslog-ng container image is based on Debian Stable. However, we’ve been getting requests for an RPM-based image for many years. So, I made an initial version available based on Alma Linux and now I need your feedback about it!

  https://www.syslog-ng.com/community/b/blog/posts/experimental-syslog-ng-container-image-based-on-alma-linux

  WEBINARS

  • New webinar: “Performance tuning for syslog-ng deployments”. You can register for it at https://www.syslog-ng.com/event/performance-tuning-for-syslog-ng-deployments/

  • You can learn about upcoming webinars and browse recordings of past webinars at https://www.syslog-ng.com/events/

  Your feedback and news, or tips about the next issue are welcome. To read this newsletter online, visit: https://syslog-ng.com/blog/

January 15, 2025

• Josef Strzibny Adding button loader to Turbo-powered forms

  Turbo is a great way to build user interfaces, but most Turbo forms have to wait for the server response. Here’s how I am adding a small loading spinner to the submit buttons to improve the UX.

  Submit feedback

  Whenever we submit a Turbo form, we are waiting for a response from the server without any big visual changes. This is especially noticable inside modals and on slow connections.

  To improve the situation we’ll create a small Stimulus controller that can be attached to any such form and suggests everything is working despite the wait:

  

  Here’s the implementation of our small controller for lazy forms:

  import { Controller } from "@hotwired/stimulus";
  
  // Connects to data-controller="lazy-form"
  export default class extends Controller {
    static targets = ["button"];
  
    submit(event) {
      const button = this.buttonTarget;
  
      // Preserve the button's current width and height
      const buttonWidth = button.offsetWidth + "px";
      const buttonHeight = button.offsetHeight + "px";
      button.style.width = buttonWidth;
      button.style.height = buttonHeight;
  
      // Change the button text and disable it
      button.innerHTML = '<span class="small-loader"></span>';
      button.disabled = true;
    }
  }
  

  The controller’s only job is to update the button without any interference to the submission process. I find it best when the button’s width doesn’t change, but you can change it to whatever’s needed.

  You might also want to style the disabled state e.g. with cursor: wait; at least.

  This can then be added to any form at hand:

  <%= form_tag resource_path, method: :post, data: { turbo: true, controller: "lazy-form", action: "submit->lazy-form#submit" } do %>
    ...
    <%= button_tag "Submit", class: "button is-primary", data: { "lazy-form-target": "button" } %>
  <% end %>
  

  Alternatives

  There is also data-turbo-submits-with which let’s you avoid writing Stimulus controller for simple cases.

• Copr Log Detective can now explain build log failures

  We’re thrilled to announce the new functionality of Log Detective. The service can now explain in detail a build log of your choice. Click on logdetective.com/explain, paste a link to your log, wait one minute and you should see a description of important lines with the overall explanation.

  Disclaimer

  This is our initial prototype of this functionality. We appreciate all your feedback. Please be patient, as there will be service disruptions, instability, and usability issues.

  • 1ï¸�⃣ The service can process only one request at a time. We understand this is very limiting, especially when multiple people will use the service at the same time. You may need to wait several minutes to get a reply in such a case. We are thankful to the Fedora Project for sponsoring our infrastructure needs. Please, reach out to us if you have experience in running LLM inference in parallel on a single GPU. We will scale the service later based on the demand in usage.

  • ğŸŒ� We are using a general-purpose LLM in the background. The data we are collecting are not being utilized just yet in the answers. We still don’t have enough data to fine-tune a model that would provide high-quality answers. Our goal for 2025 is to research and train such a model.

  • 🔬 The functionality is highly experimental. Our team has worked diligently to deliver this prototype. However, this represents only a fraction of the service’s full potential. We eagerly welcome all feedback and would greatly appreciate it if you could report any unusual behavior, errors, or tracebacks that you encounter.

  Step-by-step guide

  The new functionality is available under “Explain logs�.

  https://logdetective.com/explain

  

  The service only accepts links to raw logs; all of these are always available for Copr and Koji builds.

  

  Upon submission, Log Detective retrieves the log file and initiates the processing phase. During this process, the service interacts with the underlying LLM through multiple requests. It usually takes one minute to return an answer.

  

  The result is split into two sections:

  • The left side contains an overall explanation for the whole log.

  • Log Detective uses Drain to select important lines from the log. You can see descriptions of them on the right side after you expand them by clicking on a line.

  In our example here, we can see the build failed because a required library libtree-sitter.so.0.23()(64bit) is not available and cannot be installed. Log Detective attempts to explain this issue, though it fails with the solution: it’s not as easy as just installing the library with dnf. There is definitely room for improvement in the final answer.

  This is where you can help. If you are not satisfied with the answer and know a better one, head over to Log Detective website homepage, enter the log link and annotate it for us. Once we fine-tune our own model, the service can provide much better explanations thanks to you.

  You can reach us at the Fedora Copr build tools discussion Matrix channel: #buildsys:fedoraproject.org. Please open issues in: github.com/fedora-copr/logdetective-website/issues/new/choose

January 14, 2025

• Adam Williamson New laptop and Silverblue update

  Figured I'd post an update on how things are going with the new laptop (HP Omnibook Ultra 14, AMD Ryzen AI 9 365 "Strix Point", for the searchers) and with Silverblue.

  I managed to work around the hub issue by swapping out the fancy $300 Thunderbolt hub for a $40 USB-C hub off Amazon. This comes with limitations - you're only going to get a single 4k 60Hz external display, and limited bandwidth for anything else - but it's sufficient for my needs, and makes me regret buying the fancy hub in the first place. It seems to work 100% reliably on startup, reboot and across suspend/resume. There's still clearly something wrong with Thunderbolt handling in the kernel, but it's not my problem any more.

  The poor performance of some sites in Firefox turned out to be tied to the hanging problem - I'd disabled graphics acceleration in Firefox, which helped with the hanging, but was causing the appalling performance on Google sites and others. I've now cargo-culted a set of kernel args - amdgpu.dcdebugmask=0x800 amdgpu.lockup_timeout=100000 drm.vblankoffdelay=0 - which seem to be helping; I turned graphics acceleration back on in Firefox and it hasn't started hanging again. At least, I haven't had random hangs for the last few days, and this morning I played a video on youtube and the system has not hung since then. I've no idea how bad they are for battery life, but hey, they seem to be keeping things stable. So, the system is pretty workable at this point. I've been using it full-time, haven't had to go back to the old one.

  I'm also feeling better about Silverblue as a main OS this time. A lot of things seem to have got better. The toolbox container experience is pretty smooth now. I managed to get adb working inside a container by putting these udev rules in /etc/udev/rules.d. It seems like I have to kill and re-start the adb server any time the phone disconnects or reboots - usually adb would keep seeing the phone just fine across those events - but it's a minor inconvenience. I had to print something yesterday, was worried for a moment that I'd have to figure out how to get hp-setup to do its thing, but then...Silverblue saw my ancient HP printer on the network, let me print to it, and it worked, all without any manual setup at all. It seems to be working over IPP, but I'm a bit surprised, as the printer is from 2010 or 2011 and I don't think it worked before. But I'm not complaining!

  I haven't had any real issues with app availability so far. All the desktop apps I need to use are available as flatpaks, and the toolbox container handles CLI stuff. I'm running Firefox (baked-in version), Evolution, gedit, ptyxis (built-in), liferea, nheko, slack and vesktop (for discord) without any trouble. LibreOffice and GIMP flatpaks also work fine. Everything's really been pretty smooth.

  I do have a couple of tweaks in my bashrc (I put them in a file in ~/.bashrc.d, which is a neat invention) that other Atomic users might find useful...

  if [ -n "$container" ]
  then
    alias gedit="flatpak-spawn --host /var/lib/flatpak/exports/bin/org.gnome.gedit"
    alias xdg-open=flatpak-xdg-open
  else
    alias gedit=/var/lib/flatpak/exports/bin/org.gnome.gedit
  fi
  

  the gedit aliases let me do gedit somefile either inside or outside a container, and the file just opens in my existing gedit instance. Can't really live without that. You can adapt it for anything that's a flatpak app on the host. The xdg-open alias within containers similar makes xdg-open somefile within the container do the same as it would outside the container.

  So it's still early days, but I'm optimistic I'll keep this setup this time. I might try rebasing to the bootc build soon.

• Fedora fans دانلود کتاب هوش مصنوعی منبع باز برای توسعه دهندگان

  

  کتاب الکترونیکی Open source AI به بررسی ترکیب جذاب متن‌باز و هوش مصنوعی (AI) می‌پردازد و مزایای مدل‌ها و ابزارهای دارای مجوز متن‌باز را برای توسعه‌دهندگان به نمایش می‌گذارد. هوش مصنوعی متن‌باز برای توسعه‌دهندگان به معرفی و بررسی ویژگی‌های کلیدی Red Hat OpenShift AI می‌پردازد. این ویژگی‌ها شامل Jupyter Notebooks، PyTorch، ابزارهای پیشرفته پایش و […]

  The post دانلود کتاب هوش مصنوعی منبع باز برای توسعه دهندگان first appeared on طرفداران فدورا.

January 13, 2025

• Jon Chiappetta The M4 Mac Mini Is An Amazing Headless Network Appliance In Terms Of Size & Performance (The Heart Of My Setup)!

  I run a number of things on it, including:

  • Extra Attachments (Sonnet Solo10G & OWC 1M2)
  • Linux VMs (routing & firewalling for the network)
  • File Sharing (media server for the AppleTV)
  • Web Services (remote control for my mbp from my iphone)
  • Backup Server

  • 

  •