GPL(GENERAL PUBLIC LICENSE) FREEDOM 0:
The freedom to run the program as you wish, for any purpose.
FREEDOM 1:
The freedom to study how the program works, and change it so it does your computing as you wish.
FREEDOM 2:
The freedom to redistribute copies so you can help others.
FREEDOM 3:
The freedom to distribute copies of your modified versions to others.

nixtml is a static website generator that transforms Markdown content into HTML and integrates directly with Nix flakes.

The post nixtml – static website generator appeared first on LinuxLinks.

Read the full article on GamingOnLinux.

VirtualBox 7.2.14 open-source virtualization software is now available for download with initial support for Linux kernel 7.2, better support for updated RHEL 9.8 and 9.9 kernels, and more.

The post VirtualBox 7.2.14 Released with Initial Support for Linux Kernel 7.2 appeared first on 9to5Linux - do not reproduce this article without permission. This RSS feed is intended for readers, not scrapers.

Prometheus stores every metric it collects in its own time-series database (TSDB). Over time, this database grows, and if your

If you’ve ever needed to install Fedora Linux on a headless server, a Raspberry Pi, or any machine without a monitor attached, you’ve probably reached for VNC or RDP. They work – but as the installer moves to a web-based interface, there’s a new opportunity to do something more native to that model. We’re building it, and we want your input before we go too far down a path that’s hard to reverse.

Why This Is Happening

The Anaconda installer’s Web UI first landed in Fedora Linux 42 Workstation and was extended to all Live spins in Fedora Linux 43. It’s a full graphical installer built on Cockpit tooling and using PatternFly widgets. The GUI is rendered in a fullscreen browser window – but until now, that browser had to be running on the same machine you’re installing onto.

Here’s the thing: VNC and RDP were built around the GTK interface. While RDP could technically work with the Web UI too (it operates at the display level), a remote browser is a much better fit – orders of magnitude less data and much lower UI latency. As the Web UI becomes the primary installer interface across Fedora Linux editions, it needs its own native remote access story.

On top of that, there are two more forces pushing in the same direction.

As browsers move toward Flatpak packaging – already the reality for atomic desktops and derivatives like Bazzite – remote installation opens an opportunity for shipping focused, smaller boot images that don’t need to bundle a local browser at all. A lightweight ISO aimed at headless and network install scenarios, where the assumption is that you’re connecting from another machine.

And once you have a browser-rendered installer, serving it to a remote browser is the natural next step anyway. A headless ARM SBC doesn’t need to run a GPU-accelerated browser locally just to show you a disk partitioning screen. Your laptop can do that for it.

What It Actually Is

The concept is pretty straightforward: Anaconda’s Web UI, already built on Cockpit, gets served over HTTPS. You point a browser at the machine you’re installing, authenticate with a PIN, and you’re controlling the installation remotely. No VNC client, no RDP client, no X forwarding. Just a browser.

If you’ve used Cockpit to manage a server, you already have a feel for the experience. The difference is that the machine you’re connecting to is mid-install, not running a full OS.

Use Cases

The ones we’ve talked through most:

Headless servers – You’re installing onto a server in a rack with no attached display. You expose the Web UI over the network and control everything from your workstation.

Lightweight ARM SBCs – Devices like Raspberry Pi have limited resources. With remote rendering, the Pi just runs the installer backend; all the UI rendering happens on whatever machine you’re connecting from.

Remote monitoring – Even if you’re not fully headless, being able to watch an installation from another machine is genuinely useful. Kick off a server install, go make coffee, check progress from your laptop.

The Design Decisions So Far

We’ve had some meaty discussions about how this should work, and a few things are now settled.

Authentication: You set a PIN through kickstart or boot options, and type it into the browser login page. Same pattern as VNC and RDP – the user provides the password, not the system.

TLS with self-signed certificates: The connection is encrypted, but the certificate is generated on the fly at boot. That means your browser will show the “this certificate isn’t trusted” warning. We’ve accepted this tradeoff – shipping a private key on installation media is a security risk, and the IP address isn’t known ahead of time, so standard PKI doesn’t really apply. For environments that need proper certificates (say, a university deploying at scale), Image Builder is likely the right path to embed custom certs. That’s a later problem.

Single connection only: Only one browser session can connect at a time. Two concurrent sessions could genuinely conflict – one session starting installation while another changes the storage configuration. So: one connection, full stop.

Reconnection behavior: If you disconnect and reconnect, what happens depends on where the installation was. Before the review screen – the point of no return – you start from step one. After the review screen (installation actually running), you land on the progress view. Simple two-state model, covers the critical cases.

Config isolation and port: All Cockpit configuration specific to remote installation lives in /etc/anaconda/cockpit/, not the default Cockpit paths – otherwise the config could leak into the installed system. We’re leaning toward port 443 by default so you can just point your browser at the machine’s IP without specifying a port, but the port will also be configurable.

How This Compares to VNC and RDP

VNC has been around in Anaconda for years; RDP support was added more recently. Both work by screen-sharing the GTK interface. Technically, RDP could work with the Web UI too – it operates at the display level, scraping pixels from the screen. But a remote browser is simply better: you send orders of magnitude less data and get much lower UI latency compared to streaming a full desktop.

Beyond performance, there are practical advantages. No client is required – any modern browser works. No VNC viewer to install, no RDP client to configure, no protocol quirks across platforms. And it’s the same Web UI we’re already actively developing, so features and fixes automatically benefit the remote experience. With VNC or RDP, you’re screen-sharing a separate GTK codebase – a separate maintenance burden.

VNC and RDP aren’t going away for now – they still work with the GTK legacy interface. But as the Web UI becomes the default across more Fedora Linux editions, browser-based remote access is where the investment goes.

Where We Are Right Now

This is a developer preview. Here’s what’s working:

• Custom login page with PIN-based authentication
• Separate socket-activated systemd unit for auth (clean separation from the main Cockpit process)
• Session cookies that survive tab closes, require re-login on browser close
• Cockpit config in an isolated, anaconda-owned path

Here’s what’s still open:

• Single-connection enforcement (this will likely require close collaboration with the Cockpit team)
• Backend detection of whether installation is already running (this is needed for proper reconnection behavior)

If you want to see the PoC in action, there’s a draft PR at rhinstaller/anaconda-webui#1274 with the authentication setup – custom login page, pin-based auth script, socket-activated systemd units, and the Cockpit config override. To try it yourself, clone the PR branch, build an updates image, and boot it with virt-install:

git clone -b poc-remote https://github.com/bruno-fs/anaconda-webui.git
cd anaconda-webui
make create-updates.img

virt-install \
  --name anaconda-remote-test \
  --ram 4096 \
  --vcpus 2 \
  --disk size=20 \
  --location /path/to/Fedora-Everything-netinst-x86_64-Rawhide.iso \
  --extra-arg "inst.updates=http://your-host:port/updates.img" \
  --extra-arg "inst.webui.remote"

This is a proof of concept, not production-ready code. The PIN is hardcoded to 1234, there’s no TLS, and single-connection enforcement isn’t in place yet. Don’t use this for real installations – it’s meant to show the direction and let you poke at the approach. Once the installer boots, point a browser at the VM’s IP and enter 1234 on the login page. It’s rough, but it runs.

What We Want to Hear From You

We’re sharing this now because some of these decisions are hard to unwind once the feature ships, and community input is more useful now than after the fact. A few things we’re genuinely thinking about:

Remote installation is opt-in – you enable it through boot options or kickstart. But here’s a question we’re genuinely considering: should we ship a lightweight boot ISO without a local browser, with remote installation enabled by default? A minimal image aimed at headless and network install scenarios, where the assumption is that you’re connecting from another machine. Would that be useful to you? And if you’re using VNC or RDP for remote installation today, would this replace them? What would it need to do that it doesn’t yet?

Come talk to us on Matrix (#anaconda:fedoraproject.org), or leave a comment on this article. You can also follow the work on the anaconda-webui GitHub repo. We’re looking forward to hearing from you.

Michael Catanzaro is stepping away from managing GNOME's security issue tracking, a role he has held largely by himself since November 2020, with support from Red Hat. He calls the work mostly administrative, following each report from the moment it lands to whenever it gets fixed or the clock runs out, and requesting a CVE once that happens.

Come November 1, 2026, Michael will stop tracking newly reported security issues, only focusing on issues that were already in the pipeline before that date. By December 1, he anticipates that every disclosure deadline tied to that remaining batch will have passed, and his part in handling issues will be done.

Alongside that, he is also changing how GNOME handles vulnerability reports overall. Pointing to the rise of AI-generated security submissions, he says that for issues reported on or after August 1, 2026, the disclosure deadline is now just 30 days, a 60-day drop from 90.

And projects that ban AI-generated contributions have to take note. Any security issues submitted to GNOME Security won't be forwarded to such projects, given how much of what comes in today carries AI involvement. Michael will instead close the report in GNOME Security's own tracker and reach out to the project's maintainers directly to flag that it exists.

Someone needs to step up

Michael is currently looking for someone to take the role over, but not just anyone. He wants an experienced member of the GNOME community, someone who already knows their way around the project, to step in.

He's offered to help whoever takes it on get started, but is clear that this isn't a good task for newcomers.

Whoever takes over would inherit the workflow that runs through a form on security.gnome.org, which funnels submissions to a security team that aims to acknowledge new reports within two business days.

Whatever gets submitted through that form is used to open a confidential issue on GitLab, which is then assigned to the relevant project maintainer as the primary handler.

They would also need to take over the archaic way of keeping track of all the security issues for GNOME, which is a basic wiki page on GNOME's GitLab instance. It has to be updated manually, with every new report, fix, and disclosure going into separate tables split by year and project.

Other Linux projects already run something closer to that. Ubuntu publishes searchable, filterable security notices tied to CVE IDs. Fedora and Red Hat route tracking through Bugzilla instead, where a parent bug logs the underlying flaw, with separate tracking bugs filed against each affected package.

You can go through Michael's announcement for more information.

Read more of this story at Slashdot.

It's now possible to test experimental features on the Gnome desktop without worrying that you'll break things.