Arch Installer Goes 4.0 With a New Face and Fewer 'Curses'

Arch Linux needs no introduction around here. It is the distro people flock to for its no-nonsense, rolling release approach and, of course, the right to say "I use Arch, btw" at every given opportunity.

Setting it up used to mean having the wiki open in one window and a terminal in another, hoping you didn't miss a step. Arch Installer (archinstall) changed that.

It is Arch's official guided installer that is bundled with the live ISO. It takes you through the whole process, from disk partitioning to desktop environment selection, without requiring you to memorize yet another command. I have used it while installing an Arch-based distro in the past (Omarchy), and it was quite reliable.

The developers have now introduced Arch Installer 4.0, and it is a major overhaul.

What to expect?

Video courtesy of Sreenath.

We begin with the most obvious change, where Arch Installer has ditched curses, the old C library powering most terminal interfaces you've come across, in favor of Textual, a Python TUI framework by Textualize.io.

This brings a cleaner look, and menus are now async too, with the installer running as a single persistent Textual app throughout rather than spinning up a new instance for each selection. This means the user interface won't freeze or stall between selections while the installer is doing work in the background.

Moving on, you can now set up a firewall during installation, with firewalld available right from the menu. GRUB also picks up Unified Kernel Image (UKI) menu entry support. A Btrfs bug that had the installer choking on partitions with no mountpoints assigned has been fixed too.

On the translation front, Galician and Nepali are in as new languages, and a good chunk of the existing ones, Italian, Japanese, Turkish, Hungarian, Ukrainian, Czech, Finnish, Spanish, and Hindi included, have been refreshed.

Worth noting too is that Arch Installer 4.1 has already arrived shortly after, and it drops the NVIDIA proprietary driver option since nvidia-dkms is no longer in the Arch repos.

Closing words

You can grab the latest Arch Linux ISO to try the new installer or update an existing live ISO by running pacman -Syu. For the full changelog, head to the releases page on GitHub.

Arch Linux

---

Suggested Read 📖: Wayland’s most annoying bug is getting fixed

from It's FOSS https://ift.tt/uvzRedi
via IFTTT

GNOME 50 Drops Google Drive Integration (For Valid Reasons)

Almost two weeks ago, someone on GNOME's Discourse forum asked whether the missing Google Drive support in GNOME 50 was a bug or a deliberate decision.

GNOME developer Emmanuele Bassi replied, confirming that Drive was no longer supported.

He went on saying that libgdata, the library that coordinates communication between GNOME apps and Google's APIs, has gone without a maintainer for nearly four years. Furthermore, GVFS dropped its libgdata dependency about ten months ago, and GNOME Online Accounts now checks for that before offering the Files toggle under its Google provider settings at all.

Emmanuele suggested that anyone wanting to restore the feature should reach out to the GVFS maintainer. Chiming in on this, Michael Catanzaro, another GNOME developer, said that libgdata has since been archived on GitLab (linked above), leaving nothing to even contribute to at this point.

Further explaining that:

GNOME had already disabled this functionality years ago, but distros sometimes move slowly. If Fedora had disabled it sooner, then perhaps users would have noticed the problem before the project was archived rather than after. Oh well.

Back in December 2022, Catanzaro had already put out a public call for someone to take over libgdata, warning that the integrations depending on it would eventually stop working if nobody did. That was over three years ago, and nobody ever stepped up.

The issue was not just libgdata itself. It was the only remaining reason libsoup2 was still present in the GNOME stack, at a time when libsoup2 was already being phased out ahead of the GNOME 44 release.

Currently, Debian's security tracker lists many open CVEs against it, covering everything from HTTP request smuggling to authentication flaws. Keeping libgdata around meant keeping all of those spicy vulnerabilities around too.

A long shot, but…

I like to be delulu every so often, and I think that maybe Google could officially step in? Assigning a developer or two to bring back Drive support could get things rolling; I am aware that they don't have any shortage of talent after all.

Plus, they are already known to be supporters of open source. Seeing their recent f*ckups, this could be a good win for both their PR team and GNOME users who rely on such support.

---

Suggested Read 📖: GNOME 50 is here, but ditches X11

from It's FOSS https://ift.tt/0HmL3DX
via IFTTT