"AI" Hype or LLM Slop is Not About Efficiency, It's About Lowering Standards
Some people hypothesise this is LLM slop, delivered to paying customers to "save money" (read: fewer staff):
Had a human authored this, obvious cosmetic and substantial errors would get caught.
Lately there have been a lot of blog posts by Red Hat about "AI". About 50% of all the blog posts are something about "AI" and the company's activities in social control media are also focused on buzzwords like these.
At IBM, in general, there seems to be somewhat of a sick obsession with "AI". As somebody put it 10 hours ago, citing "IBM Says that CMOs Must Fix What’s Beneath the Surface to Fully Unlock AI": "Alright then, we are now going to get marketing advice from IBM... because marketing fails because of "fragmented operations" now... (some study they did says) [...]"
The sole comment there says: "So they go and tell clients, "oh, your marketing s_u_c_k_s because of your operations, then you can implement AI, then you'll have it all pretty for your marketing thingy, say in 1-2 years from now".... cost of million, market moved on, no luck, "sorry, dear client, but it's because you are too slow, let's fix operations again, and then do the AI marketing thingy again" (more millions)"
As a reminder, about a year ago IBM made deep cuts to Fedora operations while advertising "AI" jobs in Fedora. It wanted more buzzwords, less substance.
Will IBM replace more workers with underpaid labour and automation (done poorly) under the guise of "hey hi revolution" (or "era" or "arms race" or whatever)?
Are there layoffs happening this week?
We are still waiting to see how things unfold at Red Hat, where the chief executive officer , Matt Hicks, said last time they had mass layoffs: "The core of Red Hat is our people. It is cliche to say that decisions like this are not personal. For everyone impacted, this is personal. Your contributions helped make Red Hat what it is, and I’m grateful for everything you brought to this company. I’m genuinely sorry we weren’t able to find ways to incorporate your talents here longer."
He was announcing layoffs, but it was a bit vague and coincided with sites shutting down (the site they said would replace opensource.com has been inactive for over a month now). There's nothing from IBM yet regarding layoffs (WARN notices). However, hours ago somebody said about Red Hat: "Heard about 3 managers in our division. No idea who though. Just email from on high."
I've checked to see if people announce departures. In Fedora all I found was this:
Just don't say "girls" or "housekeeping" or other bad words which objectify women.
The layoffs can be implemented in many small phases without them being reported 'in bulk'. Or, as we stated yesterday, they could be delayed.
As someone put it hours ago, "no layoff numbers from the Red Hat yet? Did the event get postponed for: 1) More declines in the IBM stock price expected this week or 2) The delayed rollout of the "Ask Alvind" tool on w3 due to inadequate testing and answers from Alvinds non-existent fan base?"
Efficiency by removing staff isn't really efficiency but downsizing. Based on this recent report from a former Red Hat employee, Fedora is already understaffed. To quote:
Most of the proposals involve removing criteria from the list of release blockers; that does not mean that a feature or deliverable will no longer be included, it simply changes the priority of any bugs related to the features or deliverables to be non-blocking. If there is a bug found in one of the de-prioritized areas during testing for a new Fedora release, it will not delay the release.
One of the full proposals so far is dropping optical-media boot as a release-blocking feature. This should not be too controversial; most laptops and desktops do not even include a CD-ROM or DVD-ROM drive of any sort these days. Even if a system has optical media, it should also be capable of booting from a USB drive.
The team also wants to drop dual-booting from Intel-based Apple hardware as a release blocker. Again, this seems like a feature that is of limited relevance now that Apple has phased out Intel systems in favor of its own Arm-based silicon and is dropping support for those systems with newer releases of macOS. At any rate, the testing team lacks the hardware to test Intel dual-boot; in October last year, Páral had to put out a call for someone with an Intel-based Mac to test dual-booting Fedora with macOS because the quality team had no such hardware to test with. Igor Jagec answered the call then, but it is easy to see why the quality team is unwilling to block releases for hardware it has to go scrounging for.
Another proposal seeks to pare down the list of applications that are release-blocking for the Workstation edition. Right now the criteria says that, for Workstation on x86_64, ""all applications installed by default which can be launched from the Activities menu"" must have basic functionality or it's a release-blocking bug. Páral makes the case that this criteria has ""multiple long-standing issues"" such as a lack of agreement on what "basic functionality" actually means and that leads to problems during blocker-review meetings. That is compounded by the fact that bugs in these applications tend to be found very close to the final release, and that automating testing of those applications is particularly difficult and the time spent could be better used on other work.
The quality team would also like to limit the release-blocking status of BIOS systems to specific and simple-to-test scenarios. The team's justification for this is that it considers BIOS-only systems to be a rarity at this point, and available UEFI hardware that has a compatibility-support module (CSM) for BIOS is getting harder to find.
That does not mean Fedora users with older BIOS-based hardware would be entirely out in the cold. For example, it would still be a release blocker if Fedora will not install on BIOS-based systems ""which use the default automatic partitioning layout to a single empty SATA or NVMe drive"". But bugs that affect more complex partitioning layouts or alternative storage types would no longer be considered release blocking. Bugs that impact upgrading Fedora systems with a BIOS would also be considered blockers, and Fedora's cloud images will require BIOS support because Xen on AWS EC2 still uses BIOS boot.
Right now, the criteria for Fedora 43 include ""all applications installed by default which can be launched from the Activities menu"" for Fedora Workstation on x86_64. The testing team has proposed dropping that criteria and limiting release-blocking applications to a list of 11 basic applications, such as the default web browser, file manager, image viewer, and system settings. Culling the list, Páral said, may reduce the quality of less-critical applications, but it would ""reduce the likelihood of long blocker arguments, pre-release crunches and stress"".
In the interest of having fewer arguments about blocker bugs, the team also wants to be ""stricter about changes between Beta and Final"" unless the changes were agreed on ahead of time. That seems likely to be approved by FESCo, depending on the details in the final proposal.
The author could note that not many people (except IBM staff) still engage in any way with Fedora. Instead he gave this explanation: "So far, the quality scope-reduction announcement has not generated as much response as one might expect. This is probably, at least in part, because it's peak vacation season in much of the Northern Hemisphere; many of the usual participants in Fedora discussions may be enjoying time away from their computers. It may also be because of the venue chosen for the discussion; Páral asked that feedback be restricted to the Discourse forum when he sent the announcement to the fedora-devel mailing list. Fedora is a project with a long history, and many of its participants still prefer to discuss things via email rather than web forums."
It does not seem like IBM is genuinely committed to the same goals (or commitments) as the original Red Hat. █