23 Feb 2024

feedFedora People

Zach Oglesby

I track the books I read on my blog and have loose goals of how many books I want to read a year, but I have been rereading the Stormlight Archive books this year in preparation for the release of book 5. Questioning if I should count them or not.

23 Feb 2024 2:14pm GMT

Fedora fans: آموزش نصب و استفاده از ابزار TFSwitch



اگر از Terraform استفاده می کنید و پروژه های مختلفی دارید که هر کدام از آنها دارای نسخه های متفاوتی از Terraformهستند، شاید نصب و حذف نسخه های مختلف Terraform روی سیستم جهت کار با آن پروژه ها ساده و منطقی نباشد.راه حل استفاده از ‌tfswitch است. ابزار خط فرمان tfswitch به شما امکان می دهد بین نسخه های مختلف terraform سوئیچ کنید. اگر نسخه خاصی از terraform را نصب نکرده اید، tfswitch به شما امکان می دهد نسخه مورد نظر خود را دانلود کنید. نصب سریع و آسان است. پس از نصب، با اجرای دستور tfswitch به سادگی نسخه مورد نیاز خود را از منوی کشویی انتخاب کنید و شروع به استفاده از terraform کنید.
روش دیگر اینکه، کافیست تا وارد پروژه ی Terraform خود شوید و سپس دستور tfswitch را اجرا کنید. ابزار tfswitch فایل provider.tf یا version.tf و یا هر فایل دیگری که نسخه Terraform پروژه را مشخص کرده اید را می خواند و بصورت خودکار همان نسخه از Terraform را دانلود و نصب می کند.

نصب TFSwitch در لینوکس

برای نصب tfswitch در لینوکس کافیست تا دستور زیر را با کاربر root اجرا کنید:

# curl -L https://raw.githubusercontent.com/warrensbox/terraform-switcher/release/install.sh | bash

The post آموزش نصب و استفاده از ابزار TFSwitch first appeared on طرفداران فدورا.

23 Feb 2024 1:57pm GMT

Kiwi TCMS: Anonymous analytics via Plausible.io

Since the very beginning when we launched Kiwi TCMS our team has been struggling to understand how many people use it, how active these users are, which pages & functionality they spend the most time with, how many installations of Kiwi TCMS are out there in the wild and which exactly versions are the most used ones!

We reached over 2 million downloads without any analytics inside the application because we do not want to intrude on our users' privacy and this has not been easy! Inspired by a recent presentation we learned about Plausible Analytics - GDPR, CCPA and cookie law compliant, open source site analytics tool - and decided to use it! You can check-out how it works here.

What is changing

Starting with Kiwi TCMS v13.1 anonymous analytics will be enabled for statistical purposes. Our goal is to track overall usage patterns inside the Kiwi TCMS application(s), not to track individual visitors. All the data is in aggregate only. No personal data is sent to Plausible.

Anonymous analytics are enabled on this website, inside our official container images and for all tenants provisioned under https://*.tenant.kiwitcms.org. Running containers will report back to Plausible Analytics every 5 days to send the version number of Kiwi TCMS, nothing else! Here's a preview of what it looks like:

"preview of versions report"

You can examine our source code here and here.

Staying true to our open source nature we've made the kiwitcms.org stats dashboard publicly available immediately! In several months we are going to carefully examine the stats collected by the kiwitcms-container dashboard and consider making them publicly available as well! Most likely we will!

Who uses Plausible

A number of [open source] organizations have publicly endorsed the use of Plausible Analytics:

You can also inspect this huge list of Websites using Plausible Analytics compiled by a 3rd party vendor!

How can I opt-out

IMPORTANT: Private Tenant customers and demo instance users cannot opt-out! Given that they are consuming digital resources hosted by our own team they have already shared more information with us than what gets sent to Plausible! Note that we do not track individual users, analyze or sell your information to 3rd parties even across our own digital properties!

Happy Testing!

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

23 Feb 2024 10:15am GMT

Fedora Community Blog: Infra & RelEng Update – Week 8 2024

This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. It also contains updates for CPE (Community Platform Engineering) Team as the CPE initiatives are mostly tied to I&R work.

We provide you with both an infographic and a text version of the weekly report. If you want to quickly look at what we did, just look at the infographic. If you are interested in more in-depth details look at the infographic.

Week: 19 February - 23 February 2024

Read more: Infra & RelEng Update - Week 8 2024 <figure class="wp-block-image size-full wp-lightbox-container" data-wp-context="{ "core": { "image": { "imageLoaded": false, "initialized": false, "lightboxEnabled": false, "hideAnimationEnabled": false, "preloadInitialized": false, "lightboxAnimation": "zoom", "imageUploadedSrc": "https://communityblog.fedoraproject.org/wp-content/uploads/2024/02/Weekly-Report_week8.jpg", "imageCurrentSrc": "", "targetWidth": "1006", "targetHeight": "994", "scaleAttr": "", "dialogLabel": "Enlarged image" } } }" data-wp-interactive="data-wp-interactive">I&R infographic


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

CentOS Infra including CentOS CI

Release Engineering

CPE Initiatives


Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special Interest Group that creates, maintains, and manages a high quality set of additional packages for Enterprise Linux, including, but not limited to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), Oracle Linux (OL).


Matrix Native Zodbot

With ongoing stability issues with the Matrix <-> IRC bridge and many contributors switching over to Matrix, zodbot has become increasingly unreliable. The bridge is currently shut off completely. This initiative will provide a future proof solution and allow us to conduct meetings without wasting time troubleshooting the bridge and zodbot.


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

The post Infra & RelEng Update - Week 8 2024 appeared first on Fedora Community Blog.

23 Feb 2024 10:00am GMT

22 Feb 2024

feedFedora People

Justin M. Forbes: Fedora and older XFS filesystem format V4

Upstream deprecated the V4 format for XFS with commit b96cb835. With next year being the date that it defaults to unsupported (though can be enabled with a kernel config for a while still). As such, Fedora 40 will be the last release that supports these older XFS filesystems. Once Fedora 40 is EOL around June of 2025, the default Fedora kernel will no longer be able to mount them.

22 Feb 2024 1:40pm GMT

21 Feb 2024

feedFedora People

Michel Lind: Hello Nushell!

After about two years of on-and-off work, I'm happy to report that Nushell has finally landed in Fedora and EPEL 9, and can be installed simply using sudo dnf --refresh install nu on Fedora and your favorite Enterprise Linux distribution (I'm partial to CentOS Stream myself, but also RHEL, AlmaLinux, etc.) (For those not familiar with Nushell yet, think of it as a cross-platform Powershell written in Rust - it lets you manipulate pipelines of structured data, the way you might be using jc and jq with a regular shell)

21 Feb 2024 12:00am GMT

20 Feb 2024

feedFedora People

Adam Young: Anatomy of a Jam Performance

My Band, The Standard Deviants, had a rehearsal this weekend. As usual, I tried to record some of it. As so often happens, our best performance was our warm up tune. This time, we performed a tune called "The SMF Blues" by my good friend Paul Campagna.

<figure class="wp-block-embed is-type-video is-provider-youtube wp-block-embed-youtube wp-embed-aspect-16-9 wp-has-aspect-ratio">

<iframe allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen="allowfullscreen" frameborder="0" height="329" src="https://www.youtube.com/embed/ZWs9G1dTfJA?feature=oembed" title="SMF Blues" width="584"></iframe>


What is going on here? Quite a bit. People talk about Jazz as improvisation, but that does not mean that "Everything" is made up on the spot. It takes a lot of preparation in order for it to be spontaneous. Here are some of the things that make it possible to "just jam."

Blues Funk

While no one in the band besides me knew the tune before this session, the format of the tune is a 12 bar blues. This is probably the most common format for a jam tune. A lot has been written on the format elsewhere, so I won't detail here. All of the members of this group know a 12 bar blues, and can jump in to one after hearing the main melody once or twice.

The beat is a rock/funk beat set by Dave, our Drummer. This is a beat that we all know. This is also a beat that Dave has probably put 1000 hours into playing and mastering in different scenarios. Steve, on Bass, has played a beat like this his whole career. We all know the feel and do not have to think about it.

This song has a really strong turn around on the last two bars of the form. It is high pitched, repeated, and lets everyone know where we are anchored in the song. It also tells people when a verse is over, and we reset.


The saxophone plays a lead role in this music, and I give directions to the members of the band. This is not to "boss" people around, but rather to reduce the number of options at any given point so that we as a unit know what to do. Since we can't really talk in this scenario, the directions have to be simple. There are three main ways I give signals to the band.

The simplest is to step up an play. As a lead instrument, the saxophone communicates via sound to the rest of the band one of two things; either we are playing the head again, or I am taking a solo. The only person that really has to majorly change their behavior is Adam 12 on Trombone. Either he plays the melody with me or he moves into a supporting role. The rest of the band just adjusts their energy accordingly. We play louder for a repetition of the head, and they back off a bit for a solo.

The second way I give signals to the band is by direct eye contact. All I have to do is look back at Dave in the middle of a verse to let him know that the next verse is his to solo. We have played together long enough that he knows what that means. I reinforce the message by stepping to the side and letting the focus shift to him.

The third way is to use hand gestures. As a sax player, I have to make these brief, as I need two hands to play many of the notes. However, there are alternative fingerings, so for short periods, I can play with just my left hand, and use my right to signal. The most obvious signal here is the 4 finger hand gesture I gave to Adam 12 that we are going to trade 4s. This means that each of us play for four measures and then switch. If I gave this signal to all of the band, it would mean that we would be trading 4s with the drums, which we do on longer form songs. Another variation of this is 2s, which is just a short spot for each person.

One of the wonderful thing about playing with this band is how even "mistakes" such as when i tried to end the tune, and no one caught the signal…and it became a bass solo that ended up perfectly placed. Steve realized we all quieted out, and that is an indication for the Bass to step up, and he did.

Practice Practice Practice

Everyone here knows their instrument. We have all been playing for many decades, and know what to do. But the horn is a harsh mistress, and she demands attention. As someone once said:

Skip a day and you know. Skip two days and your friends know. Skip three days and everyone knows.

Musical Wisdom from the ages

Adam 12 is the newest member of the band. It had been several years since he played regularly before he joined us. His first jam sessions were fairly short. We have since heard the results of the hard work that he has put in.

I try to play every day. It completes with many other responsibilities and activities in modern life. But my days seems less complete if I did not at least blow a few notes through the horn.


Music is timing. Our ears are super sensitive to changes in timing, whether at the micro level, translating to differences in pitch, or the macro level, with changes in tempo…which is just another word for time. Dave is the master of listening. He catches on to a pattern one of us it playing and he works it into his drumming constantly. Steve is the backbone of the band. Listening to the bass line tells us what we need to know about speed and location in the song. The more we play together, the more we pick up on each others cues through playing. The end effect is that we are jointly contributing to an event, an experience, a performance.

20 Feb 2024 10:53pm GMT

19 Feb 2024

feedFedora People

Matthew Garrett: Debugging an odd inability to stream video

We have a cabin out in the forest, and when I say "out in the forest" I mean "in a national forest subject to regulation by the US Forest Service" which means there's an extremely thick book describing the things we're allowed to do and (somewhat longer) not allowed to do. It's also down in the bottom of a valley surrounded by tall trees (the whole "forest" bit). There used to be AT&T copper but all that infrastructure burned down in a big fire back in 2021 and AT&T no longer supply new copper links, and Starlink isn't viable because of the whole "bottom of a valley surrounded by tall trees" thing along with regulations that prohibit us from putting up a big pole with a dish on top. Thankfully there's LTE towers nearby, so I'm simply using cellular data. Unfortunately my provider rate limits connections to video streaming services in order to push them down to roughly SD resolution. The easy workaround is just to VPN back to somewhere else, which in my case is just a Wireguard link back to San Francisco.

This worked perfectly for most things, but some streaming services simply wouldn't work at all. Attempting to load the video would just spin forever. Running tcpdump at the local end of the VPN endpoint showed a connection being established, some packets being exchanged, and then… nothing. The remote service appeared to just stop sending packets. Tcpdumping the remote end of the VPN showed the same thing. It wasn't until I looked at the traffic on the VPN endpoint's external interface that things began to become clear.

This probably needs some background. Most network infrastructure has a maximum allowable packet size, which is referred to as the Maximum Transmission Unit or MTU. For ethernet this defaults to 1500 bytes, and these days most links are able to handle packets of at least this size, so it's pretty typical to just assume that you'll be able to send a 1500 byte packet. But what's important to remember is that that doesn't mean you have 1500 bytes of packet payload - that 1500 bytes includes whatever protocol level headers are on there. For TCP/IP you're typically looking at spending around 40 bytes on the headers, leaving somewhere around 1460 bytes of usable payload. And if you're using a VPN, things get annoying. In this case the original packet becomes the payload of a new packet, which means it needs another set of TCP (or UDP) and IP headers, and probably also some VPN header. This still all needs to fit inside the MTU of the link the VPN packet is being sent over, so if the MTU of that is 1500, the effective MTU of the VPN interface has to be lower. For Wireguard, this works out to an effective MTU of 1420 bytes. That means simply sending a 1500 byte packet over a Wireguard (or any other VPN) link won't work - adding the additional headers gives you a total packet size of over 1500 bytes, and that won't fit into the underlying link's MTU of 1500.

And yet, things work. But how? Faced with a packet that's too big to fit into a link, there are two choices - break the packet up into multiple smaller packets ("fragmentation") or tell whoever's sending the packet to send smaller packets. Fragmentation seems like the obvious answer, so I'd encourage you to read Valerie Aurora's article on how fragmentation is more complicated than you think. tl;dr - if you can avoid fragmentation then you're going to have a better life. You can explicitly indicate that you don't want your packets to be fragmented by setting the Don't Fragment bit in your IP header, and then when your packet hits a link where your packet exceeds the link MTU it'll send back a packet telling the remote that it's too big, what the actual MTU is, and the remote will resend a smaller packet. This avoids all the hassle of handling fragments in exchange for the cost of a retransmit the first time the MTU is exceeded. It also typically works these days, which wasn't always the case - people had a nasty habit of dropping the ICMP packets telling the remote that the packet was too big, which broke everything.

What I saw when I tcpdumped on the remote VPN endpoint's external interface was that the connection was getting established, and then a 1500 byte packet would arrive (this is kind of the behaviour you'd expect for video - the connection handshaking involves a bunch of relatively small packets, and then once you start sending the video stream itself you start sending packets that are as large as possible in order to minimise overhead). This 1500 byte packet wouldn't fit down the Wireguard link, so the endpoint sent back an ICMP packet to the remote telling it to send smaller packets. The remote should then have sent a new, smaller packet - instead, about a second after sending the first 1500 byte packet, it sent that same 1500 byte packet. This is consistent with it ignoring the ICMP notification and just behaving as if the packet had been dropped.

All the services that were failing were failing in identical ways, and all were using Fastly as their CDN. I complained about this on social media and then somehow ended up in contact with the engineering team responsible for this sort of thing - I sent them a packet dump of the failure, they were able to reproduce it, and it got fixed. Hurray!

(Between me identifying the problem and it getting fixed I was able to work around it. The TCP header includes a Maximum Segment Size (MSS) field, which indicates the maximum size of the payload for this connection. iptables allows you to rewrite this, so on the VPN endpoint I simply rewrote the MSS to be small enough that the packets would fit inside the Wireguard MTU. This isn't a complete fix since it's done at the TCP level rather than the IP level - so any large UDP packets would still end up breaking)

I've no idea what the underlying issue was, and at the client end the failure was entirely opaque: the remote simply stopped sending me packets. The only reason I was able to debug this at all was because I controlled the other end of the VPN as well, and even then I wouldn't have been able to do anything about it other than being in the fortuitous situation of someone able to do something about it seeing my post. How many people go through their lives dealing with things just being broken and having no idea why, and how do we fix that?

(Edit: thanks to this comment, it sounds like the underlying issue was a kernel bug that Fastly developed a fix for - under certain configurations, the kernel fails to associate the MTU update with the egress interface and so it continues sending overly large packets)

comment count unavailable comments

19 Feb 2024 10:30pm GMT

Weekly status of Packit Team: Week 7 in Packit

Week 7 (February 13th - February 19th)

19 Feb 2024 12:00am GMT

Josh Bressers: Episode 416 – Thomas Depierre on open source in Europe

Josh and Kurt talk to Thomas Depierre about some of the European efforts to secure software. We touch on the CRA, MDA, FOSDEM, and more. As expected Thomas drops a huge amount of knowledge on what's happening in open source. We close the show with a lot of ideas around how to move the needle for open source. It's not easy, but it is possible.

<audio class="wp-audio-shortcode" controls="controls" id="audio-3321-1" preload="none" style="width: 100%;"><source src="https://traffic.libsyn.com/opensourcesecuritypodcast/Episode_416_Thomas_Depierre_on_open_source_in_Europe.mp3?_=1" type="audio/mpeg">https://traffic.libsyn.com/opensourcesecuritypodcast/Episode_416_Thomas_Depierre_on_open_source_in_Europe.mp3</audio>

Show Notes

19 Feb 2024 12:00am GMT

18 Feb 2024

feedFedora People

Jon Chiappetta: New Samsung S90C OLED – Green Screen Of Death

So last year, for my birthday, I purchased a new Sony PS5 to update my gaming console after soo many years and it immediately failed on me by always shutting down during game play. This year, for my birthday, I decided to try and update my 8 year old TV with a new Samsung OLED for the first time and as my luck would have it, I was presented with the "Green Screen Of Death". The TV only just arrived a few days ago and is now dead so I have to go through the process of trying to contact a certified Samsung repair person to see if it can even be fixed. I can't tell if its just my bad luck going on lately or if quality control at these companies has gone down hill but it's starting to get harder and harder to find good quality alternatives! 😦

<figure class="wp-block-embed aligncenter is-type-video is-provider-youtube wp-block-embed-youtube wp-embed-aspect-16-9 wp-has-aspect-ratio">

<iframe allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen="allowfullscreen" frameborder="0" height="567" src="https://www.youtube.com/embed/vjmcboqltgA?feature=oembed" title="New Samsung S90C OLED - Green Screen Of Death" width="1008"></iframe>

</figure> <figure class="wp-block-embed aligncenter is-type-video is-provider-youtube wp-block-embed-youtube wp-embed-aspect-16-9 wp-has-aspect-ratio">

<iframe allowfullscreen="true" class="youtube-player" height="567" sandbox="allow-scripts allow-same-origin allow-popups allow-presentation allow-popups-to-escape-sandbox" src="https://www.youtube.com/embed/cyWlACuhqNg?version=3&amp;rel=1&amp;showsearch=0&amp;showinfo=1&amp;iv_load_policy=1&amp;fs=1&amp;hl=en&amp;autohide=2&amp;wmode=transparent" style="border:0;" width="1008"></iframe>


18 Feb 2024 11:56pm GMT

Steven Pritchard: Data Recovery with Open-Source Tools (part 1)

This is material from a class I taught a long time ago. Some of it may still be useful. 🙂

The original copyright notice:

Copyright © 2009-2010 Steven Pritchard / K&S Pritchard Enterprises, Inc.

This work is licensed under the Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 United States License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-nd/3.0/us/ or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA.

This is part 1 of a multi-part series.

Identifying drives

An easy way to get a list of drives attached to a system is to run fdisk -l. The output will look something like this:

# fdisk -l

Disk /dev/sda: 80.0 GB, 80026361856 bytes

255 heads, 63 sectors/track, 9729 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Disk identifier: 0xcab10bee

Device Boot Start End Blocks Id System

/dev/sda1 * 1 8673 69665841 7 HPFS/NTFS

/dev/sda2 8675 9729 8474287+ c W95 FAT32 (LBA)

In many cases, you'll see a lot of (generally) uninteresting devices that are named /dev/dm-n. These are devices created by device mapper for everything from software RAID to LVM logical volumes. If you are primarily interested in the physical drives attached to a system, you can suppress the extra output of fdisk -l with a little bit of sed. Try the following:

fdisk -l 2>&1 | sed '/\/dev\/dm-/,/^$/d' | uniq

Whole devices generally show up as /dev/sdx (/dev/sda, /dev/sdb, etc.) or /dev/hdx (/dev/hda, /dev/hdb, etc.). Partitions on the individual devices show up as /dev/sdxn (/dev/sda1, /dev/sda2, etc.), or, in the case of longer device names, the name of the device with pn appended (an example might be /dev/mapper/loop0p1).



The vast majority of hard drives currently in use connect to a computer using either an IDE (or Parallel ATA) interface or a SATA (Serial ATA) interface. For the most part, SATA is just IDE with a different connector, but when SATA came out, the old Linux IDE driver had accumulated enough cruft that a new SATA driver (libata) was developed to support SATA controller chipsets. Later, the libata driver had support for most IDE controllers added, obsoleting the old IDE driver.

There are some differences in the two drivers, and often those differences directly impact data recovery. One difference is device naming. The old IDE driver named devices /dev/hdx, where x is determined by the position of the drive.

/dev/hda Master device, primary controller

/dev/hdb Slave device, primary controller

/dev/hdc Master device, secondary controller

/dev/hdd Slave device, secondary controller

And so on.

Unlike the IDE driver, the libata driver uses what was historically SCSI device naming, /dev/sdx, where x starts at "a" and increments upwards as devices are detected, which means that device names are more-or-less random, and won't be consistent across reboots.

The other major difference between the old IDE driver and the libata driver that affects data recovery is how the drivers handle DMA (direct memory access). The ATA specification allows for various PIO (Programmed I/O) and DMA modes. Both the old IDE driver and the libata driver will determine the best mode, in most cases choosing a DMA mode initially, and falling back to a PIO mode in error conditions. The old IDE driver would also let you manually toggle DMA off and on for any device using the command hdparm.

hdparm -d /dev/hdx Query DMA on/off state for /dev/hdx

hdparm -d0 /dev/hdx Disable DMA on /dev/hdx

hdparm -d1 /dev/hdx Enable DMA on /dev/hdx

The libata driver currently lacks the ability to toggle DMA on a running system, but it can be turned off for all hard drives with the kernel command line option libata.dma=6, or for all devices (including optical drives) with libata.dma=0. On a running system, the value of libata.dma can be found in /sys/module/libata/parameters/dma. (The full list of numeric values for this option can be found in http://www.kernel.org/doc/Documentation/kernel-parameters.txt.) There does not appear to be a way to way to toggle DMA per device with the libata driver.

There are several reasons why you might want to toggle DMA on or off for a drive. In some cases, failing drives simply won't work unless DMA is disabled, or even in some rare cases might not work unless DMA is enabled. In some cases the computer might have issues when reading from a failing drive with DMA enabled. (The libata driver usually handles these situations fairly well. The old IDE driver only began to handle these situations well in recent years.)

In addition to those reasons, PIO mode forces a drive to a maximum speed of 25MB/s (PIO Mode 6, others are even slower), while DMA modes can go up to 133MB/s. Some drives appear to work better at these lower speeds.


While SCSI drives and controllers are less common than they once were, all current hard drive controller interfaces now use the kernel SCSI device layers for device management and such. For example, all devices that use the SCSI layer will show up in /proc/scsi/scsi.

# cat /proc/scsi/scsi

Attached devices:

Host: scsi0 Channel: 00 Id: 00 Lun: 00

Vendor: TSSTcorp Model: CD/DVDW TS-L632D Rev: AS05

Type: CD-ROM ANSI SCSI revision: 05

Host: scsi1 Channel: 00 Id: 00 Lun: 00

Vendor: ATA Model: ST9160821A Rev: 3.AL

Type: Direct-Access ANSI SCSI revision: 05

Host: scsi3 Channel: 00 Id: 00 Lun: 00

Vendor: ATA Model: WDC WD10EACS-00Z Rev: 01.0

Type: Direct-Access ANSI SCSI revision: 05

In most cases, it is safe to remove a device that isn't currently mounted, but to be absolutely sure it is safe, you can also explicitly tell the kernel to disable a device by writing to /proc/scsi/scsi. For example, to remove the third device (the Western Digital drive in this example), you could do the following:

echo scsi remove-single-device 3 0 0 0 > /proc/scsi/scsi

Note that the four numbers correspond to the controller, channel, ID, and LUN in the example.

In cases where hot-added devices don't automatically show up, there is also a corresponding add-single-device command.

When recovering data from SCSI (and SCSI-like drives such as SAS), there are no special tricks like DMA.

USB, etc.

The Linux USB drivers are rather resilient in the face of errors, so no special consideration needs to be given when recovering data from thumb drives and other flash memory (except that these devices tend to work or not, and, of course, dead shorts across USB ports are a Bad Thing). USB-to-ATA bridge devices are a different matter entirely though. They tend to lock up hard or otherwise behave badly when they hit errors on a failing drive. Generally speaking, they should be avoided for failing drives, but drives that are OK other than a trashed filesystem or partition table should be completely fine on a USB-to-ATA bridge device.

To be continued in part 2.

18 Feb 2024 5:57pm GMT

Arnulfo Reyes: El Alto Costo de Volar

El incidente con el vuelo 1282 de Alaska Airlines, en el que se desprendió una puerta de salida de emergencia de un Boeing 737-MAX9 en pleno vuelo, ha reavivado la discusión sobre la decadencia de Boeing como fabricante de aviones. Este avión pertenece a la misma familia 737 MAX que sufrió dos accidentes mortales en 2018 y 2019.


La mayoría de las fuentes apuntan al mismo evento desencadenante: la fusión de 1997 con McDonnell-Douglas, que transformó a Boeing de una empresa impulsada por la ingeniería y enfocada en construir los mejores aviones posibles, a una que se centra abrumadoramente en las finanzas y el precio de las acciones.

Esta descripción parece precisa, pero omite una gran parte del panorama: la brutal estructura de la industria de aviones comerciales que impulsa a empresas como Boeing a crear cosas como el 737 MAX (una actualización de un avión de 50 años) en lugar de crear un nuevo modelo desde cero. Al desglosar cómo funciona la industria de aviones comerciales, podemos comprender mejor el comportamiento de Boeing.

Las palabras de George Ball, director gerente de Lehman Brothers en 1982, y Jean Pierson, ex CEO de Airbus, resuenan con fuerza en este contexto: "No hay precedentes históricos ni paralelos actuales para la magnitud del riesgo de exposición financiera asumido por una empresa de estructuras aéreas estadounidense" y "No puedes ganar, no puedes salirte a mano, y no puedes renunciar". Estas citas subrayan la complejidad y los desafíos inherentes a la industria de la aviación comercial.

El riesgo de desarrollar un nuevo avión

La fabricación de aviones comerciales es similar a cualquier otra industria manufacturera en algunos aspectos. Una empresa desarrolla un producto y trata de venderlo por un precio suficiente para cubrir los costos de desarrollo y producción. Si tiene éxito y genera ganancias, continúa desarrollando nuevos productos; si no, cierra sus operaciones. Lo que distingue a la industria de la aviación es la escala en la que ocurren estas cosas.

Desarrollar un avión comercial es increíblemente costoso. Los presupuestos para nuevos programas de desarrollo de aeronaves están en los miles de millones de dólares, y los inevitables sobrecostos pueden llevar los costos de desarrollo a $20-30 mil millones o más.


Esto no es simplemente un caso de empresas modernas e infladas que han olvidado cómo hacer las cosas de manera eficiente (aunque hay algo de eso): desarrollar un avión a reacción siempre ha sido costoso. Boeing gastó entre $1.2 y $2 mil millones para desarrollar el 747 a finales de los años 60 (~$10-20 mil millones en dólares de 2023), y otros fabricantes de la época como Lockheed y McDonnell-Douglas señalaron que sus propios costos de desarrollo de nuevos aviones eran similares.

El costo de desarrollar un nuevo avión comercial puede ser una fracción significativa, si no mayor, del valor total de la empresa. Por ejemplo, Boeing gastó $186 millones en el desarrollo de su primer avión a reacción en 1952, el 707, que era $36 millones más de lo que valía la empresa.

Cuando Boeing comenzó el desarrollo del 747 en 1965, la empresa estaba valorada en $375 millones, menos de un tercio de lo que gastó en el desarrollo del 747. La mayoría de los otros programas no son tan desequilibrados, pero aún representan un riesgo enorme. Se estima que el Boeing 777 costó entre $12 y $14 mil millones para desarrollar en un momento en que Boeing valía alrededor de $30 mil millones. Y cuando Airbus lanzó el programa A380, presupuestó $10.7 mil millones, la mitad del valor de la empresa (y mucho menos de lo que finalmente se gastó). Los fabricantes de aviones a menudo apuestan por la empresa cuando deciden desarrollar un nuevo modelo de jet.

Gastar miles de millones de dólares en el desarrollo de nuevos productos no es exclusivo de la industria de la aviación: un nuevo modelo de automóvil costará miles de millones de dólares para desarrollar, al igual que un nuevo medicamento. Pero tanto los automóviles como los medicamentos pueden distribuir sus costos de desarrollo entre millones de ventas de productos. El mercado de aviones comerciales, por otro lado, es mucho más pequeño; solo se venden alrededor de 1,000 jets grandes cada año. Los fabricantes de aviones necesitan poder recuperar los miles de millones gastados en el desarrollo de productos, fábricas y herramientas con solo unos pocos cientos de ventas.

Esto crea algunas dificultades para los fabricantes de aviones. Por un lado, hace que las curvas de aprendizaje sean muy importantes. Las curvas de aprendizaje son el fenómeno por el cual los costos de producción (o alguna medida relacionada, como las horas de trabajo) tienden a caer un porcentaje constante por cada duplicación acumulativa del volumen de producción: pasar de 10 a 20 unidades producidas produce la misma disminución porcentual de costos que pasar de 10,000 a 20,000.

Los productos de alto volumen pasan la mayor parte de su tiempo en una porción relativamente "plana" de la curva de aprendizaje, donde las duplicaciones están cada vez más separadas. Si has producido 1,000,000 de algo, si haces otros 500 o 5,000 no hará casi ninguna diferencia en términos de la curva de aprendizaje. Pero si solo has hecho 50 de algo, hacer otros 500 hace una gran diferencia en el nivel de reducción de costos que se puede lograr. Por lo tanto, si solo planeas vender unos pocos cientos de algo, un número relativamente pequeño de ventas tendrá un gran impacto en cuán eficientemente estás produciendo y cuán rentable eres.

Los fabricantes de aviones comerciales dependen de obtener suficientes pedidos para empujarlos lo suficientemente lejos en la curva de aprendizaje donde están ganando suficiente dinero por avión para recuperar los costos de desarrollarlo. Los primeros aviones podrían producirse de manera tan ineficiente que se venden por menos de lo que cuesta hacerlos. Esto es típicamente en el vecindario de 500 aviones (y podría ser mucho más si un programa se excede mucho del presupuesto); vende menos, y el programa perderá dinero.

El número relativamente pequeño de ventas de aviones también crea una intensa presión para predecir con precisión las tendencias en los viajes aéreos. Los fabricantes necesitan patinar donde estará el disco: desarrollar el tipo de avión que las aerolíneas querrán durante muchos años en el futuro.

Adivinar mal puede ser desastroso. Airbus perdió enormes cantidades de dinero cuando malinterpretó el mercado para su enorme A380 (solo vendió 251 aviones, muy por debajo de lo que se necesitaba para equilibrar, y el último A380 salió de la línea en 2021). Airbus proyectó que el crecimiento continuo en los viajes aéreos crearía demanda para un avión aún más grande que pudiera mover pasajeros de manera económica entre los grandes aeropuertos centrales. Pero, de hecho, los viajes internacionales se fragmentaron, y las aerolíneas vuelan cada vez más vuelos directos entre destinos utilizando aviones más pequeños y fáciles de llenar como el Boeing 787. A finales de la década de 1960, Lockheed y McDonnell-Douglas se arruinaron mutuamente al desarrollar cada uno un nuevo avión (el L-1011 y el DC-10, respectivamente) para lo que resultó ser un mercado muy pequeño: se vendieron menos de 700 aviones entre ellos. Lockheed terminó abandonando el mercado de aviones comerciales después de perder $2.5 mil millones en el programa (~$9 mil millones en dólares de 2023), y McDonnell-Douglas nunca se recuperó, finalmente se vendió a Boeing en 1997 a medida que su participación en el mercado disminuyó y no pudo financiar el desarrollo de nuevos aviones.

Pero adivinar bien viene con sus propios problemas. Si un programa se retrasa, eso puede causar pedidos perdidos, falta de confianza de las aerolíneas y, en última instancia, llevar a los clientes a los brazos de un competidor. Boeing originalmente planeó introducir su 787 en 2008, pero se retrasó hasta 2011, lo que llevó a los clientes a comprar el Airbus A330 (Airbus se jactó de que vendió más A330 después de que Boeing lanzó el 787). Si Boeing hubiera entregado a tiempo, su ventaja sobre Airbus habría sido enorme.

Y tener demasiados pedidos para un nuevo avión puede ser casi tan malo como tener muy pocos. A finales de la década de 1960, Douglas se ahogó en una demanda inesperadamente alta para su DC-9: no pudo cumplir con sus plazos de entrega, se vio obligado a pagar compensación a las aerolíneas afectadas y casi se vio obligado a la quiebra debido a problemas de flujo de efectivo, lo que resultó en una fusión con McDonnell Aircraft. Boeing tuvo una lucha similar al tratar de aumentar rápidamente la producción de su 737 revisado (llamado 737 Next Generation, o NG) a mediados de la década de 1990: finalmente se vio obligado a detener temporalmente la producción debido al caos, lo que resultó en entregas tardías (y penalizaciones asociadas) y una pérdida neta para el año 1997, la primera de la compañía desde 1959. Se estima que Boeing perdió mil millones de dólares en los primeros 400 737NG, a pesar de que eran derivados de un avión que Boeing había estado construyendo desde la década de 1960.

Los eventos globales pueden cambiar rápidamente las tendencias en los viajes aéreos, cambiando completamente los tipos de aviones que las aerolíneas quieren comprar. Airbus, por ejemplo, tuvo poco éxito inicial vendiendo su primer modelo, el A300. En 1978, cuatro años después de su introducción, solo había vendido 38 de ellos. Pero el aumento de los precios del combustible debido a la segunda crisis del petróleo, junto con la creciente competencia de las aerolíneas, creó una demanda para un avión de pasajeros de fuselaje ancho y dos motores eficientes en combustible, y solo el A300 cumplía con los requisitos. Para 1979, las ventas habían aumentado a más de 300. De manera similar, la desregulación de la industria de las aerolíneas en Estados Unidos obligó a las aerolíneas a ser mucho más competitivas en precio y a centrarse en cosas como la eficiencia del combustible y el costo operativo. Esto cambió el cálculo de los tipos de aviones que estaban interesados en comprar, y aumentó la demanda de aviones como el 737 de Boeing.

A menudo, el éxito se reduce a la suerte tanto como a cualquier otra cosa.

Airbus tuvo suerte cuando los precios del petróleo en alza significaron que su A300 estaba de repente en alta demanda y no tenía competencia. Boeing tuvo suerte con su 737 en la década de 1960, que entró en servicio más de dos años después del similar DC-9, y solo tuvo éxito en parte debido a los retrasos en la producción de Douglas. Y Boeing tuvo suerte nuevamente con el 747, que, al igual que el A380, era un avión enorme que pocas aerolíneas realmente necesitaban. Solo tuvo éxito porque Juan Trippe, el fundador de Pan Am, los compró por capricho (a Trippe le gustaba tener los aviones más recientes y "no veía la necesidad de un análisis de mercado"). Otras aerolíneas siguieron su ejemplo, sin querer conceder a Pan Am el beneficio de marketing de tener los aviones más grandes (aunque el 747 se volvió cada vez más útil a medida que aumentaban los viajes internacionales).

Los fabricantes de aviones se enfrentan a la ingrata tarea de intentar navegar este panorama mientras arriesgan miles de millones de dólares. Pero, por supuesto, desarrollar nuevos productos no es una opción: al igual que en cualquier otra industria, los competidores intentan asegurar su propia ventaja al promocionar sus productos a un número limitado de clientes. La tecnología de los aviones está cambiando constantemente, y las aerolíneas (en una competencia brutal por sí mismas) quieren todas las últimas tecnologías: mejor aerodinámica, materiales más ligeros, motores más grandes y más eficientes, etc., que reducirán sus costos operativos y mejorarán la experiencia de sus pasajeros. Perder incluso un pedido puede ser un gran revés para un fabricante de aviones, tanto por el pequeño número de clientes en general como porque las ventas tienden a tener impulso: una venta a una aerolínea probablemente signifique más ventas futuras a esa aerolínea (ya que habrá eficiencias de la flota común en cosas como el mantenimiento compartido y la formación), o ventas a aerolíneas asociadas, o ventas a competidores que quieren apostar por el caballo ganador. Las aerolíneas son muy conscientes del hecho de que pocas ventas pueden poner a un fabricante de aviones en terreno peligroso, lo que hace arriesgado para una aerolínea engancharse a un perdedor.

Si un fabricante de aviones puede navegar con éxito por este panorama, la recompensa es una ganancia insignificante: entre 1970 y 2010, Boeing, el constructor de aviones comerciales más exitoso, promedió poco más del 5% de ganancia anual. No es de extrañar que la feroz y costosa competencia y las ganancias miserables hayan expulsado gradualmente a los competidores del espacio, dejando solo a Boeing y Airbus (y, si te sientes generoso, a Bombardier y Embraer). Empresas como de Havilland, Dassault, Lockheed, Douglas, Convair, Glen Martin, todas han sido expulsadas o forzadas a fusionarse. Al observar la historia de la fabricación de aviones a reacción en 1982, John Newhouse estima que, de los 22 aviones a reacción comerciales que se habían desarrollado hasta entonces, solo dos, el Boeing 707 y el Boeing 727, se creía que habían ganado dinero (aunque señala que el 747 podría eventualmente hacer esa lista también).

El resultado de estas dificultades es que los fabricantes de aviones piensan muy cuidadosamente antes de desarrollar un nuevo avión: los riesgos son grandes, las recompensas pequeñas e inciertas. A menudo, es una apuesta mucho más segura simplemente desarrollar una modificación de un modelo existente, manteniendo el mismo fuselaje básico y agregando motores más eficientes o una forma de ala ajustada, o estirándolo para agregar más capacidad de pasajeros. Revisar un modelo existente puede costar solo el 10-20% de diseñar un nuevo avión desde cero, y puede proporcionar casi tantos beneficios. El típico avión nuevo podría ser un 20-30% más eficiente en combustible que los diseños existentes, pero Boeing pudo lograr una mejora del 15-16% con el 737 MAX revisado. Y actualizar un modelo existente también es más barato para las aerolíneas, no tienen que volver a entrenar a sus pilotos para volar el nuevo avión.

Para ver cómo se ve este tipo de cálculo en la práctica, echemos un vistazo a la historia del Boeing 737, que ha sido revisado y actualizado repetidamente desde su primer vuelo en 1967.

Evolución del Boeing 737

Boeing desarrolló por primera vez el 737 a mediados de la década de 1960 como un avión de corto alcance y pequeña capacidad para completar su línea de productos y prevenir que Douglas se quedara con todo el mercado de gama baja con su DC-9. Inicialmente, no fue particularmente exitoso, ni se esperaba que lo fuera: Douglas llevaba una ventaja de 2 años con el DC-9, y el 727 anterior de Boeing ya estaba sirviendo gran parte de ese mercado, aunque con 3 motores en lugar de los 2 motores más eficientes del 737. De hecho, el programa estuvo a punto de ser cancelado poco después de su lanzamiento debido a las bajas ventas iniciales. Para minimizar el costo y el tiempo de desarrollo, el 737 fue diseñado para compartir tantas piezas como fuera posible con los anteriores 707 y 727.

El rendimiento inicial del 737 fue menor de lo esperado, por lo que Boeing desarrolló una versión "avanzada" con aerodinámica mejorada en 1970. Pero incluso con estas mejoras, las luchas de Douglas para construir el DC-9, y un pedido para una versión militar del 737 (The T-43A trainer), las ventas aún eran lentas. El avión se estaba construyendo a una tasa de solo dos por mes, y hasta 1973 el programa estuvo al borde de ser cancelado (durante este período, Boeing casi quebró debido a los sobrecostos en el programa 747, y tuvo que despedir al 75 por ciento de su fuerza laboral). El 737 solo se salvó porque finalmente se estaba vendiendo por menos de sus costos de producción, pero no se esperaba que recuperara sus costos de desarrollo.

Pero las ventas comenzaron a repuntar en 1973, y la producción había alcanzado cinco aviones por mes en 1974. Para 1978, contra todo pronóstico, se había convertido en el avión de pasajeros más vendido del mundo, título que retuvo de 1980 a 1985. La desregulación de las aerolíneas en los EE. UU. había causado un cambio en la estrategia de las aerolíneas: en lugar de conectar directamente dos ciudades con vuelos de bajo volumen, comenzaron a conectar a través de aeropuertos centrales, utilizando aviones más pequeños y más baratos de operar. El 737 encajaba perfectamente en la factura.

Pero los competidores de Boeing no se quedaron quietos. Douglas lanzó una versión actualizada de su DC-9, el Super 80, con una versión mejorada de su motor Pratt and Whitney que lo hacía más silencioso y más eficiente en combustible que el 737. Para contrarrestar la amenaza, y para lidiar con las regulaciones de ruido cada vez más estrictas, Boeing respondió con el Boeing 737-300 de "nueva generación", que comenzó su desarrollo en 1981. Esta versión del 737 agregó capacidad de pasajeros, mejoró la aerodinámica y tenía un nuevo turbofán de alto bypass más eficiente de CFMI (una empresa conjunta entre GE y la empresa francesa SNECMA).

Ajustar un motor tan grande debajo del ala del 737 fue un desafío. El 737 había sido diseñado originalmente con una distancia al suelo baja para acomodar aeropuertos de "segundo nivel" con sistemas de escaleras algo limitados. Extender el tren de aterrizaje para elevar el avión habría requerido cambiar la ubicación de los pozos de las ruedas, lo que habría cambiado la estructura del avión lo suficiente como para esencialmente convertirlo en un nuevo avión. En cambio, el motor se apretó en el espacio disponible, dándole una forma elipsoide característica. Este motor de alto bypass le dio al 737-300 una mejora del 18% en eficiencia de combustible versus los aviones de generación anterior, y una mejora del 11% sobre el Super 80 de McDonnell-Douglas, mientras aún lo mantenía lo más similar posible al 737 anterior.

A medida que el 737-300 tomaba forma, surgía un nuevo competidor. Tras el éxito de su A300, Airbus comenzó el desarrollo del A320 más pequeño, un competidor directo del 737, en 1984. El A320 incorporó muchas tecnologías avanzadas, como el fly-by-wire, que reemplazó las pesadas conexiones mecánicas o hidráulicas entre los controles del avión y las superficies de control del avión con conexiones electrónicas más ligeras. Para 1987, el A320 ya había acumulado 400 pedidos, incluyendo un gran pedido de Northwest Airlines, un cliente de Boeing de larga data. Claramente iba a ser un competidor feroz.

<figure><figcaption>Concept art for the 7J7</figcaption></figure>

Algunos argumentan que Boeing podría haber (y debería haber) eliminado al A320 inmediatamente anunciando un nuevo avión "desde cero". En ese momento, Boeing estaba trabajando en un avión del tamaño del 737 llamado 7J7, que utilizaba un avanzado motor de avión "unducted fan" (UDF) de GE. Teóricamente, el 7J7 habría sido un 60% más eficiente en combustible que los aviones existentes, junto con la incorporación de tecnologías como el fly by wire. Pero el motor UDF tenía problemas técnicos sin resolver, como la alta generación de ruido, y Boeing estaba preocupado por el tiempo que llevaría llevar el 7J7 al mercado. En cambio, Boeing desarrolló otra versión estirada de su 737 (el 737-400), canceló el proyecto 7J7, y comenzó a desarrollar un avión para llenar el hueco entre su 767 y 747, el 777.

Pero a medida que el A320 continuaba invadiendo el mercado y más clientes de Boeing de larga data desertaban (como United en 1992), estaba claro que se requería un reemplazo para el 737. Muchos una vez más favorecieron el desarrollo de un avión completamente nuevo (que Airbus cree que habría sido catastrófico para el A320), pero Boeing era cauteloso con los nuevos aviones después del 777. Aunque el programa se realizó a tiempo y entregó un avión excepcional, los costos se dispararon, hasta $14 mil millones según algunas estimaciones ($28 mil millones en dólares de 2023) contra un presupuesto proyectado de $5 mil millones. En cambio, Boeing lanzó el 737 "Next Generation" (NG), otra actualización del fuselaje del 737. El 737NG presentaba, entre otras cosas, un nuevo diseño de ala, un motor más eficiente que reducía los costos de combustible en un 9% y los costos de mantenimiento en un 15%, y añadía "winglets" para mejorar la aerodinámica. El 737NG también redujo el número de piezas en un 33% en comparación con las versiones anteriores, mientras que aún conservaba suficiente similitud para requerir una mínima reentrenamiento de los pilotos y permanecer dentro de las reglas de "derivados" de la FAA.

Entregado por primera vez en diciembre de 1997, el 737NG se volvió inmensamente popular, con la versión 737-800 vendiendo más de 5000 aviones en los siguientes 20 años (aunque, como hemos señalado, aumentar la producción vino con inmensas dificultades). Sin embargo, esto no fue suficiente para enterrar al A320, que también continuó vendiéndose bien. Algunas personas de Airbus creen que un avión completamente nuevo habría sido catastrófico para el A320 a finales de los años 90.

A principios de la década de 2000, el 737 y el A320 se habían convertido en los productos más importantes de la oferta de Boeing y Airbus, y juntos representaban el 70% del mercado de aviones comerciales. Una vez más, Boeing comenzó a considerar un reemplazo para el 737 e inició un proyecto, Yellowstone, para explorar reemplazos completamente nuevos para el 737 y otros aviones de Boeing. Pero los hallazgos no fueron particularmente alentadores: sin un nuevo motor avanzado (que no estaría listo hasta 2013 o 2014), las mejoras en la eficiencia del combustible serían de un 4% como máximo. Y las tecnologías que incorporaría del 787 en desarrollo, como los compuestos avanzados, serían difíciles de escalar para la producción de alto volumen requerida para un reemplazo del 737.

Boeing se había vuelto una vez más cauteloso con los nuevos aviones debido a su experiencia con el 787, que había superado masivamente el presupuesto y se había retrasado. El nuevo Boeing, centrado en las finanzas, había sido lo suficientemente reacio a aprobar el desarrollo del 787, y ahora era aún más reacio.

Pero para 2010, con nuevos motores como el Pratt and Whitney GTF y el CFM LEAP en el horizonte, Boeing se inclinaba fuertemente hacia un reemplazo del 737 desde cero.

La mano de Boeing terminó siendo forzada por Airbus.

En 2011, Airbus comenzó a trabajar en un A320 con motores nuevos con un rendimiento significativamente mejorado, llamado A320neo (por "new engine option"), y lo utilizó para atraer parcialmente a un gran cliente de Boeing, American Airlines (que dividió un gran pedido entre Boeing y Airbus). Airbus creía que Boeing se sentiría obligado a responder con su propio motor en lugar de perder más clientes mientras desarrollaba un reemplazo desde cero. Los clientes, por su parte, habían perdido la confianza en que Boeing pudiera entregar un nuevo avión a tiempo después del desastre del 787, y también preferían que Boeing lanzara un motor con una mejor oportunidad de estar a tiempo. Un motor tendría casi todos los beneficios de un avión completamente nuevo (~15-16% de ahorro de combustible versus 20% para un típico desde cero), costaría quizás el 10-20% para desarrollar, y evitaría los costos de las aerolíneas teniendo que volver a entrenar a los pilotos, así como cosas como tener que averiguar cómo producir partes compuestas en grandes volúmenes.

El resto, por supuesto, es historia.

En lugar de un nuevo avión, Boeing desarrolló otra revisión del 737, el 737 MAX. Ajustar motores aún más grandes en el avión mientras se mantenía lo suficientemente similar para caer bajo las reglas de derivados de la FAA requería desplazarlos muy hacia adelante e inclinarlos ligeramente hacia arriba, lo que cambió ligeramente las características de rendimiento del avión. Para mantener su rendimiento similar a los 737 anteriores, Boeing creó un software, MCAS, para tratar de emular el comportamiento de los aviones anteriores. El software MCAS, y sus interacciones con varios sensores, finalmente causaron dos accidentes mortales de vuelos 737 MAX.

Conclusión: A veces pienso en cómo el límite de la posibilidad tecnológica está definido no solo por el dominio del universo, sino por los límites de la economía y las organizaciones que operan dentro de ella. Si los productos son suficientemente complejos, y la demanda es de cantidades tan pequeñas que hay un caso de negocio limitado para ellos, no los obtendremos, incluso si son físicamente posibles de construir.

Los submarinos nucleares parecen estar cerca de este límite: armas enormemente complejas que solo un puñado de organizaciones en el planeta son capaces de construir. Los aviones a reacción parecen estar dirigiéndose rápidamente a este límite exterior, si es que no están allí ya.

El costo y el nivel de tecnología requeridos, junto con el tremendo riesgo de desarrollarlos y el pequeño número de ventas en las que se pueden recuperar los costos, ya han reducido el número de proveedores a esencialmente dos (aunque quizás COMAC de China eventualmente agregue un tercer jugador), y no hay evidencia de que esté volviéndose más fácil.

18 Feb 2024 5:53pm GMT

17 Feb 2024

feedFedora People

Jens Kuehnel: podman-compose and systemd

I'm using more and more podman and especially podman-compose. podman-compose is not part of RHEL, but it is available in EPEL and it is in Fedora. Of course I run it as a non-root user. It really works great, but creating systemd unit files for podman-compose is ugly. I had it running for about a year, but I wanted to have a look for something better. This blog post talks about Fedora (tested with 39), RHEL8 and RHEL9. All have some smaller problems, but sometimes different ones.

I wanted to try Quadlet-podman for over a year. This week I had a closer look and found that it is more complicate than I thought. I really like the simple one-file solution of a compose file. I found podlet to migrate compose files to quadlet. (Use podlet musl, if you have problem with the glibc of the gnu version).

But at the end I really like to continue using the compose file that are provided by most of the tool that I use and I had only very small problems with podman-compose, all of them easy fixable. At the end I decided to use podman-compose systemd. There is not a lot of documentation, but I really liked it.

I had quite a lot of problems, but I will show you here how to fix them and how my setup is working now.

Setup as root

First things first. I run it always as non-root of course. If you do too, please do a "restorecon -R" to the homedir of the user that runs the container. audit2allow and the logs will not show the problem (you have to disable noaudit to see it - I fear), but it will interferes with the startup of your container.

You want to make sure the container user can run even when he is not loged in. So you have to enable linger with:

loginctl enable-linger USERNAME.

I enabled cgroupv2 on my RHEL8 and there is a bug that you have to fix. The Problem can be fixed by different solution, but I choose to change the file /etc/containers/containers.conf. Of course this is not needed on RHEL9 or Fedora.


To use podman-compose systemd you need a systemd template and I choose to set it up in /etc, because I have multiple user running multiple applications. (If the filename of the output of systemctl status on Fedora/RHEL9 looks strange to you. There is a link: /etc/xdg/systemd/user -> ../../systemd/user).

You can run the command podman-compose systemd -a create-unit as root. Or you can run this command as a normal user and paste the output to /etc/systemd/user/podman-compose@.service. But all platforms (podman-compose runs with version 1.0.6 on all) the template has an error that prohibits the successful startup of the containers. You have to add "-in-pod pod_%i" to the up command - thanks to RalfSchwiete. I also added the ExecStopPost line. Here my complete template:

# /etc/systemd/user/podman-compose@.service
Description=%i rootless pod (podman-compose)

ExecStartPre=-/usr/bin/podman-compose --in-pod pod_%i up --no-start
ExecStartPre=/usr/bin/podman pod start pod_%i
ExecStart=/usr/bin/podman-compose wait
ExecStop=/usr/bin/podman pod stop pod_%i
ExecStopPost=/usr/bin/podman pod rm pod_%i


As User

With the preparation as root finished, the setup as non-root is quit simple - Almost 😉 . First stop the container with "podman-compose down". Then go to the directory with the podman-compose.yml (or docker-compose.yml if you use the old name) file and run "podman-compose systemd". Be careful as this commands starts the containers again. I always stop the containers again with podman-compose down and start it up again with "systemctl -user enable -now 'podman-compose@COMPOSE ' ". Otherwise you are not sure if the systemctl command is working.

But not on Fedora and RHEL9. Here I always got the error message "Failed to connect to bus: No medium found". The solution was not to use "su - USERNAME" but instead

machinectl shell USERNAME@ 

With su the DBUS_SESSION_BUS_ADDRESS is missing on Fedora and RHEL9. This is a know issue, but RedHat states that "Using su or su - is not a currently supported mechanism of rootless podman." I'm not sure it machinectl is supported or not, but I can tell you it is working. If you never heard of machinectl before or didn't know that machinectl has a shell options - you are not alone. 🙂 The official way it to ssh as USERNAME into the maschine. (I prefer my way better :-))

Running but where are the log

If it is working you get this output at the end of the podman-compose systemd command like this:

you can use systemd commands like enable, start, stop, status, cat
all withoutsudo like this:

            systemctl --user enable --now 'podman-compose@COMPOSE'
            systemctl --user status 'podman-compose@COMPOSE'
            journalctl --user -xeu 'podman-compose@COMPOSE'

and for that to work outside a session
you might need to run the following command once

            sudo loginctl enable-linger 'USERNAME'

you can use podman commands like:

            podman pod ps
            podman pod stats 'pod_COMPOSE'
            podman pod logs --tail=10 -f 'pod_COMPOSE'

systemctl -user status 'podman-compose@COMPOSE' did work fine on RHEL8 and shows the output of the command. But on Fedora and RHEL9 it did not show anything. On all Version the command journalctl -user -xeu 'podman-compose@COMPOSE' never shows any output.

To fix this your non-root user has to become member of the systemd-journald group. But even then you have to use the right command on all Platforms. Not the one from the output above, but this instead:

journalctl  -xe --user-unit 'podman-compose@COMPOSE'

As you can see the podman-compose is quite nice, but there are a lot of stumbling block. After you know how to avoid them, it works quite well.

17 Feb 2024 9:45pm GMT

Kevin Fenzi: Some musings on matrix

The fedoraproject has moved pretty heavily toward matix in the last while, and I thought I would share some thoughts on it, good, bad, technical and social.

The technical:

The good:

The bad:

Anyhow, that's probably too much for now. See you all on matrix…

17 Feb 2024 6:21pm GMT

16 Feb 2024

feedFedora People

Adam Young: Swimming positions improvements

I have been getting in the pool for the past couple of months, with a goal of completing a triathalon this summer. Today I got some pointers on things I need to improve on in my freestyle technique.


My kick needs some serious work. I am pulling almost exclusively with my arms. As Jimmy (the lifeguard and a long time swim coach) said, "You're killing yourself."

He had me do a drill with just a kickboard. "If your thighs are not hurting you are doing it wrong." I focused on barely breaking the surface with my heels, pointing my toes, and keeping my legs relatively straight…only a slight bend.

Next he had me do a lap with small flippers. "You shouldn't fell like you are fighting them." The force you to point your toe. It felt almost too easy. We ran out of time for me to try integrating it into a regular stroke.

For weight lifting, he recommended squats.

For a sprint he recommended 3 kicks per stroke/6 per pair. For longer courses, two kicks per stroke. I think I will shoot for 2/ stroke, as I am going for 1/2 mile total.


Improving my kick will improve my whole body position, including my breathing. It seems I am pulling my head too far out of the water, mainly because my legs are dropping. Although the opposite is true, too: pulling my head too far out of the water is causing my legs to drop. The two should be fixed together.

Arm Entry

One other swimmer at the pool that I asked for advice told me to "lead with my elbows" and then to think about entering the water "like a knife through butter". Jimmy added that I should be reaching "long and lean." Like a fast sailboat.

After that, the stroke should go out, and then finish in an S.

I think I need to glide more during the initial entry of the arm into the water.

Jimmy recommended a drill, either using a kickboard or a ring, and holding that out in front, and passing it from hand to hand.

Head position

I should be looking down and to the front,while the the top of my head breaks the surface.

16 Feb 2024 6:58pm GMT