Exploring Kittens With Kitty Terminal Emulator

Kitty is a popular terminal emulator that supports many modern features. Focused on power users, it offers a wide range of customization that other terminals often lack.

For example, it includes a functional image display protocol and smooth cursor animations.

I have shown Kitty tweaking in the past, and in the regards, I would like to discuss Kittens today.

Kittens are functional units that extend the features of the Kitty terminal or work as standalone programs. They have direct access to the running Kitty instance.

Kitty comes bundled with several of these kittens, written in Go, which we will explore in detail later. You even have the option to create your own custom Kittens in Python, if you find a specific need that hasn't been solved yet.

Some Cool Default Kittens

🚧

In my opinion, it is important to remember that many kittens are Kitty terminal exclusive. Before you build muscle memory around it, make sure you aren't planning to switch to a different terminal emulator anytime soon.

Themes

Let's start with the most popular tool first. If you use Kitty daily, you have likely come across this utility at some point.

Themes is a kitten that allows you to change your terminal color scheme interactively without editing any configuration files. Kitty includes a wide variety of preset themes that you can access by running a simple command:

kitten themes

Apply themes in Kitty

In the overlay window, you can easily scroll through both dark and light themes to see a live preview. Once you find one you like, just press Enter and follow the prompts to set it as your preferred theme.

💡

Latest versions of Kitty now support automatic theme changes based on your system's dark and light mode. This is a very convenient feature if you want your terminal to stay in sync with your global OS settings.

In my opinion, this is a feature I really miss when using Ghostty. While Ghostty has a similar interface, you still have to manually edit your configuration file to apply the theme name after you pick one.

Fonts

If you have found a new font and want to set it as your terminal choice, this kitten has you covered. You can launch the interactive interface directly in your terminal using a simple command:

kitten choose-fonts

Choose Fonts

This tool allows you to perform several actions within a single interface. You can select new fonts, preview how they look, and even fine-tune specific font faces.

The utility makes it much easier to manage your typography without guessing how a font will appear in your workspace. It handles the complex parts of the setup so you can focus on finding the perfect look.

Choose files

Choose files is a comprehensive file picker designed for Kitty and other GUI applications on your system. It functions similarly to fzf but is specifically optimized for finding and managing files.

Choose Files

This tool offers several powerful features, including the ability to select multiple files at once. It intelligently respects .gitignore rules in your git directories to keep your workflow clean.

To use it, run:

kitten choose-files

You can also select non-existent files to trigger a "save file" option or choose entire directories. In my opinion, this file picker will completely change the way you interact with files in your terminal.

Quick access terminal

If you remember Yakuake in KDE, you are already familiar with the concept of a drop down terminal for quick tasks. Kitty offers similar functionality through the Quick Access Terminal Kitten.

You can launch this feature at any time using a simple command in your terminal:

kitten quick-access-terminal

0:00

/0:19

Quick Access Terminal

If you want to personalize the experience, you can customize the tool using a specific configuration file. Simply create or edit quick-access-terminal.conf inside your ~/.config/kitty/ directory to adjust its behavior.

GPU accelerated dock panel

The Panel kitten is something truly special. It creates a desktop panel for you that functions much like i3bar.

0:00

/0:13

Kitten Panel

While some might feel this is a bit overpowered for a terminal application, the panel is quite interesting for minimal use cases. It even allows you to set tools like btop as your actual desktop wallpaper.

In my opinion, this is an incredible feature for anyone who loves a unique workspace. You heard that right, and here is a great example of how it looks in action.

A diff tool

The diff kitten is an excellent tool available directly within Kitty. It offers several advanced features like side-by-side comparisons, syntax highlighting, and even image diffs or recursive directory comparisons.

To use it, you simply pass the file names as shown in the command below:

kitten diff file1 file2

Diff Files

Other interesting Kittens

I use the terminal daily for standard update tasks and editing text files. If you are deeply involved in terminal usage, there are many kittens available for very niche use cases.

For example, the Broadcast kitten allows you to type text simultaneously across multiple Kitty windows. There are also SSH related kittens designed for editing files and even a specialized SSH supported clipboard.

In my opinion, these specific tools are essential for power users who manage remote servers regularly. Feel free to experiment with these options to make your terminal life significantly more productive.

Assign keybindings/alias for quick access

All these kittens can be bound to keyboard shortcuts or aliases so you don't have to manually run the command every time. This makes your workflow much faster by giving you instant access to your favorite actions.

I will show you how I mapped the kittens in my own configuration file. It is a straightforward process that keeps everything organized and easy to access.

The most important step is to make sure your chosen keys are uniquely assigned. You want to avoid any conflicts with existing terminal options or system-wide shortcuts.

In the below code, I mapped the F1 key to get the file chooser kitten in multiple file select mode.

map f1 kitten choose-files --mode=files

Adding the following line to your shell configuration file (~/.bashrc) to add an alias to the diff tool:

alias d="kitten diff"

Now, you can run:

d file1 file2

To get the difference between them.

Another example, let's map the F2 key to get a quick access terminal:

map f2 kitten quick-access-terminal

Wrapping up

So, we have seen how kittens can improve your terminal productivity. While most of these have separate alternatives like fzf for file selection or difftastic for diffs, integrating them directly into your terminal with a clean UI is commendable.

Kitty also offers a desktop-ui kitten that lets you integrate the file picker into all your GUI apps. Since this can cause issues with some applications and is something I use rarely, it remains out of scope for this guide.

In my opinion, the seamless integration of these tools makes Kitty feel much more cohesive than a standard terminal emulator.

Did you find any of these kittens useful enough to replace your existing tools?

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

Keychron Built Open Source Firmware for Gaming Mice, and Linux Users Stand to Gain the Most

Keychron has introduced ZGM, short for Zephyr Gaming Mouse, an open source firmware project built for gaming mice.

It is built on Zephyr RTOS, the same real-time operating system that already powers ZMK for keyboards. In its announcement, Keychron portrayed the launch as a philosophy rather than a marketing angle, stating, "Open source isn't marketing for us. It's the default."

Keyboards have QMK. They have ZMK. Mice have… nothing. 🔒

Every gaming mouse on the market runs firmware you can't read, can't audit, can't change.

So we built it ourselves.

ZGM — Zephyr Gaming Mouse. Open-source firmware for gaming mice, coming Q1 2027. The G6 HE will run… pic.twitter.com/naSdDXeMBh

— Keychron (@KeychronMK) July 29, 2026

The firmware is set to debut alongside the Keychron G6 HE, with a launch window sometime between January and March 2027.

The details

ZGM isn't a mouse, and it isn't a driver or third-party tool you install after buying one either. It's firmware that runs directly on a mouse's own hardware, and only devices built with it will run it.

The G6 HE is the first confirmed device, and any wider adoption depends on whether other manufacturers choose to build around it. The project is released under the GPL-3.0 license, so anyone can inspect the code, modify it, or fork it for their own hardware.

Currently, it is in a very early stage of development, where the repository mainly holds project scaffolding and policy files right now. Keychron says firmware sources, board support, and flashing guidance are still being prepared.

The plan is for the project to grow into full Zephyr-based firmware, with configuration layers for different hardware variants and integration for sensors, buttons, scroll wheels, and lighting.

Wired support is expected to arrive first, with wireless support to follow, alongside build instructions, example hardware targets, and testing guidance for latency and reliability.

Want even more?

Just a placeholder pic of the ZGM website.

Keychron plans to support the chips Zephyr already works with, plus the sensors, buttons, scroll wheels, and lighting that go into a gaming mouse. Battery management for wireless builds is part of the plan too.

The roadmap starts where the project is now, then moves to building the actual firmware. After that comes getting buttons, scrolling, and sensors working, followed by basic USB support for wired mice.

Later steps cover different hardware setups, testing for lag and stability, and eventually wireless support and more customization. The peripherals manufacturer says this is just a tentative plan for now, not a fixed schedule.

Keychron already builds keyboards around QMK and is already going towards ZMK. Both firmwares have proven that open source software can deliver deep customization and long-term reliability through years of community development.

And, as mentioned earlier, ZMK already runs on the same Zephyr foundation ZGM uses, which likely shaped Keychron's choice to build on it for their new mouse instead of starting from scratch.

That said, ZGM has a long way to go before it matches either project. QMK and ZMK both carry years of contributions, documentation, and supported hardware, while ZGM's repository only has planning material.

Linux users gain from this

Gaming and productivity mice rarely ship with official Linux support. Most peripheral makers build their configuration software for Windows and macOS only, leaving buttons, DPI stages, and lighting profiles locked behind an app that never gets a Linux release.

Linux users are left relying on community projects that reverse engineer these devices instead, and even then, support only covers whatever protocols someone has bothered to document.

I personally use two Logitech mice, the G502 HERO and a wireless one that comes with the MK470 bundle, and neither has official software support on Linux. Both work fine plugged in directly, but configuring them means turning to third-party tools like Piper or Solaar.

If more manufacturers pivot towards an open solution like ZGM, us Linux users could at least get some QMK-like support (but for mice). Imagine the kind of keybinds and macros you could play around with.

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

And Folks, We Have a Vibe Coded Linux Distro!

Starling is a new open source Linux desktop environment. One developer built it by directing Claude for about six months, ending up with a working desktop that boots into its own session with a compositor and window manager.

Don't think of this as a themed shell bolted onto GNOME or KDE either. It brings its own X11 server, so apps like Chrome, Slack, and Zoom run on it without requiring any special modifications.

🚧

This is a vibe-coded desktop environment, still an early preview built mostly through AI prompts rather than a full engineering team. Expect bugs, security issues, missing settings, and rough edges throughout.

What is Starling?

Every part of it, like the shell, the compositor, the window manager, and the apps, are written in Swift, a language that has hardly been used for a Linux desktop before.

Most of the heavylifting here has been done using Claude, which was instructed to follow things like "Wayland only. Do not read, modify, or reference X11Server/ or X11 launch paths unless explicitly asked."

Under the hood, the framework running the whole desktop is a full port of Flutter's Dart framework to Swift. Starling brings a Wayland compositor written in C and its own X11 server, so older X11 apps still work.

That combination is what actually makes it a desktop rather than a demo.

For features, it has things like:

• A dock and Launchpad (app launcher).
• Floating and tiling window management.
• A shader-based glass effect on the dock and panels.
• Five first-party apps, including Terminal and an apt-powered App Store.

Taking it for a run

I tested Starling on an Ubuntu 26.04 LTS virtual machine, and its rough edges showed up almost immediately. Right after logging in, the resolution defaulted to a non-standard, letterboxed widescreen ratio of 5120x2160 at 2x scaling (according to Fastfetch).

I tried searching for an option to change this in the Settings menu, and the "Displays" page only had a slider for scaling, nothing for resolution itself. Things might be better if you install it on a computer directly, but that's a risk you are more than welcome to take. 🙂‍↔️

A few smaller things didn't work either. The search bar inside the Launchpad (app launcher) doesn't respond to typing, and none of the accent color swatches in Appearance actually apply once clicked.

The App Store itself works, technically. I installed Chrome through it without any errors, but the browser opened up oversized and ran noticeably laggy once it loaded. Not exactly the experience you'd want from one of the few apps the store puts at the top of its list.

Shutting the system down turned into its own small hunt. There's no power menu anywhere on the desktop, so I had to go into the Terminal and run sudo shutdown to turn it all off.

Early stages of abandonware?

Starling probably won't be the last project like this. If one developer directing an AI can produce a working desktop environment, compositor and all in about six months, expect a lot more attempts over the coming years.

Building something and keeping it alive are two very different jobs. Vibe coding gets you off the ground fast. Debugging what it produces is painfully slow, and that grind is usually what kills a developer's motivation before the project gets anywhere.

Installing Starling

Starling packages as a single DEB, built for Ubuntu 26.04 LTS on amd64. You will have to ensure that you have a Wayland-capable login manager (which the Desktop LTS release ships with).

From there, download and install the package:

curl -fLO https://github.com/starling-build/starling/releases/download/v0.2.1/starling_0.2.1-1_amd64.deb
sudo apt install ./starling_0.2.1-1_amd64.deb

Next, you have to either log out or reboot, then at the login screen click your name, open the session menu (a small gear icon at the bottom-right), and pick "Starling" from the list.

Mind you, it is quite early for this desktop. Currently on v0.2.1, the project itself is being handled by an anonymous human developer (or maybe AGI 😱?), so I would test it on a spare machine.

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

I Found a Simple Open WebUI Alternative for Running Ollama Models in a Web Browser

Running local AI models has become surprisingly accessible. Install Ollama, pull a model, and you can start chatting with it in minutes. That's exactly how I began my journey with local AI.

Using an LLM directly in terminal is okayish but it limits your ability. That's why there are so many frontends available for Ollama, providing you with a graphical, chatGPT-like interface. This way, you can easily revisit an earlier answer, copy code snippets, or have an extended discussion with a model.

Of the so many GUIs, Open WebUI is like the de facto Ollama front-end. I don't know about you but I find it difficult to set up.

I also looked at options like LibreChat, AnythingLLM, and LobeChat. They all felt geared toward users who wanted an all-in-one AI platform rather than a lightweight companion for a local Ollama UI.

This is the 'problem' that I think OrionChat solves...by its simplicity.

OrionChat: Web-based chat interface for Local LLMs

OrionChat is a free, open-source, web-based chat interface. It isn't built exclusively for Ollama. Instead, it can also talk to OpenAI, Google Gemini, Claude, Groq, Cerebras, and a few other providers.

But for this piece, I only care about one thing: how well it works as a front end for models running locally through Ollama.

It doesn't attempt to become an entire AI platform, no automation, agents, scheduled tasks. Instead, it provides a clean chat interface, model selection, and a responsive interface.

Once the models are downloaded, OrionChat simply detects them. I particularly liked this design because it doesn't introduce another layer of model management.

Installing OrionChat

Getting OrionChat running took me less than five minutes. There's no need to even run a Docker daemon.

Step 1: Clone the repository

Clone and move into the project folder.

git clone https://github.com/EliasPereirah/OrionChat.git
cd OrionChat

Step 2: Serve the files

Python makes this trivial if you already have it installed, which most Linux systems do:

python -m http.server

Step 3: Open OrionChat

Head to http://localhost:8000 in your browser. OrionChat's interface should load right away.

Letting Ollama talk to OrionChat

This is the part I actually got stuck on the first time. By default, Ollama only accepts requests from its own trusted origins, and a browser-based frontend like OrionChat doesn't automatically qualify. Every request gets silently blocked until you explicitly allow it.

Step 1: Check how you're running Ollama

If you installed Ollama via the official install script, it's almost certainly running as a systemd service. If you just launch it manually with ollama serve, skip to Step 3.

Step 2: Edit the Ollama service

You need to add the origin override to ollama.service systemd unit file.

sudo systemctl edit ollama.service

In the editor that opens, add this under the [Service] section:

[Service]
Environment="OLLAMA_ORIGINS=http://localhost"

Save, then reload and restart Ollama:

sudo systemctl daemon-reload
sudo systemctl restart ollama

Step 3: Or, if you run Ollama manually

Skip the systemd steps entirely and just set the variable inline when you launch it:

OLLAMA_ORIGINS=http://localhost ollama serve

Step 4: Confirm it worked

Refresh the OrionChat tab in your browser. It should now connect to Ollama and start listing your locally installed models. You can choose your default Ollama model and start prompting.

It provides an option to upload files and to use the microphone with Ollama models. This is a really nice feature you can't use in CLI mode.

My wxperience running Ollama models with OrionChat

Want to go from Gemma to Qwen? A couple of clicks. Want to try Mistral instead? Select it and keep going. For someone who regularly experiments with different models, this alone is worth the five-minute setup.

Starting a conversation feels exactly like using any modern AI chatbot. Code blocks render properly. Markdown formatting looks clean. Tables show up as tables instead of a mess of pipe characters. Long conversations stay easy to navigate because everything lives in an actual interface instead of a scrolling terminal buffer.

Copying responses feels natural too, no highlighting text in a terminal and fighting with line wrapping. For anyone who asks a lot of questions to local LLMs, that alone noticeably improves the day-to-day experience.

Also, unlike other Ollama UI alternatives, OrionChat is not an Electron wrapper hiding a browser inside your app menu. It lives in a web browser ;)

Final Thoughts

Ollama already made running local models easy, and for quick tests, the terminal is perfectly adequate. But if you're talking to local models for hours every week, a proper interface makes a real difference.

OrionChat hits a sweet spot for me. It doesn't require a complicated deployment, and doesn't try to become an all-in-one AI platform. It focuses on doing one thing well: giving Ollama a pleasant place to live outside the terminal.

After using it for a while, I found myself opening OrionChat first and reaching for the CLI only when managing or updating models themselves.

If you've been relying purely on the Ollama CLI and occasionally wish it felt a bit more like ChatGPT, OrionChat is worth the five minutes it takes to try.

If OrionChat isn't quite your fit, Open WebUI, Enchanted, Chatbox, LibreChat, and NextChat are all solid alternative Ollama frontends, each trading off simplicity against features differently. Worth trying a couple to see which matches your workflow.

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

GCC Compiler Bans AI Code Contribution But Sensibly

Open source projects have mostly split into two camps on AI. Some keep a human in the loop, letting contributors use whatever tools they want as long as they take responsibility for the result.

Others have gone further and banned AI-generated contributions outright, no matter who reviews them. GCC has now weighed in, and it's leaning toward the stricter camp.

It's the compiler at the heart of building software across GNU and Linux systems, so its stance on AI carries weight well beyond its own repository. The GCC Steering Committee has decided to decline what it calls "legally significant" contributions made with AI, a term we will be unpacking shortly.

AI begone?

Well yes, and no. The GCC Steering Committee has inducted a new AI policy built around one core rule. If a contribution is legally significant and any part of it traces back to an LLM, GCC won't take it.

By that, they mean what the GNU maintainer guidelines define as being legally significant, which is around 15 lines of code or text, the point where copyright actually applies. Smaller edits don't count on their own, but enough of them from the same person can still add up to it.

There's some leeway for a certain use case, though. GCC maintainers can still accept legally insignificant AI-generated contributions, as long as they're clearly marked and meet the project's usual contribution standards.

Test cases are exempted too. Even ones that would normally count as legally significant can still be AI-generated. The policy itself only covers GCC. Any code imported from other projects for convenience or dependency satisfaction falls outside its scope.

Other than that, any AI-assisted contribution now needs an "Assisted-by:" tag in its commit message, similar to what the Linux kernel adopted earlier this year.

None of this touches how contributors use AI on their own time. Screen readers, translation tools, spelling and grammar help, research, bug hunting, and patch review are all fair game, provided the actual output submitted to GCC isn't AI-generated itself.

The GCC Steering Committee expects the policy to keep evolving, shaped by community feedback and wherever the wider GNU Project lands on AI overall. The next review is set for the start of 2027.

A growing trend

Codeberg took the dramatic route last week, where its members voted 358 to 144 to ban projects built mostly from AI-generated code and to formally rule out training AI models on user data or code.

They blame server strain from AI crawlers, climbing hardware costs, and a growing pile of low-effort AI-generated contributions as the driving forces behind the decision.

LLVM went the other way at the start of this year, adopting a "human in the loop" policy. Here, contributors can use any AI tool they like, but they have to disclose which one, answer questions about their submissions, and take full responsibility for the result.

GCC's policy lands closer to Codeberg's without going as far as an outright ban. Test cases keep a narrow opening that Codeberg's rules don't, and GCC still allows small, clearly marked AI contributions that Codeberg's project-level ban wouldn't.

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

Good News Gamers! GOG is Officially Coming to Linux

GOG built its whole brand around selling DRM-free games and providing offline installers that work without requiring an internet connection or any kind of verification from their side.

They even encourage people to download installers and copy them over to physical media like discs, and treat the copy as theirs. This is something the big players in the space, Steam and Epic Games, just cannot do, since both keep your library tethered to their clients.

And don't even get me started on account standing. If you break their rules, they retain the right to suspend your account or, worse, ban it outright, leaving you locked out of your own games.

GOG GALAXY is the company's optional client that does the things one would expect from such an application. It handles auto-updates, cloud saves, achievement tracking, rollbacks for when a patch breaks your save, and pulls in game libraries from other platforms.

Sadly, none of that has ever officially arrived on Linux, as the client is only offered for Windows and macOS. Linux gamers who want it on their systems have to run the Windows client through compatibility layers like Bottles or Lutris instead of installing it directly.

What you see when you visit the GOG GALAXY website from a Linux computer.

All's not gloom though, as it has now been confirmed that a Linux build of GOG GALAXY is coming. Speaking to Liam from GamingOnLinux, the joint CEO of GOG, Krzysztof Papliński, stated that they already have a "specialist on board," and are looking for the "best way to approach Linux support."

Before you get too excited, know that there's no release window mentioned in the original email reply by Krzysztof, who notes that:

This is a significant undertaking, so while we’re not ready to share any specific plans, timelines, or results just yet, it’s very much an area we’re investing time and effort into.

Some context

This isn't appearing out of nowhere. Late last year, GOG became an independent company after CD Projekt sold it to co-founder Michał Kiciński, ending its run as a subsidiary.

A few days later, in January, Michał told PC Gamer that Windows is "poor-quality software" and that he isn't surprised people are gravitating away from the ecosystem altogether.

In the same interview, managing director Maciej Gołębiewski said Linux was already one of the things GOG had put in its strategy for the year.

Around the same time, a new job listing went up, looking for a senior software engineer, with the description referring to Linux as the next major frontier for the platform.

This is great news

Placeholder image of the Windows client for GOG GALAXY.

A native GOG GALAXY client would finally let Linux gamers manage their GOG library the same way Windows and Mac users already do. Though I am not sure if any other game platforms will be supported.

But despite that, gamers will still get to take advantage of a well-equipped launcher that handles large game libraries with ease. Which is supplemented by handy conveniences like auto-updates, cloud saves, syncing between multiple devices, and staying connected with your friends.

This matters more than you might think, btw. Nowadays, digital storefronts are the ones who have the final say over what stays in your library and what doesn't. The recent delisting of Xbox games showed us that quite clearly.

Physical media is going away too, as Sony, for instance, recently confirmed it will stop producing game discs for new PlayStation titles starting January 2028, pushing new releases into digital-only territory.

GOG's DRM-free installers and the optional client that lets you download those eliminate both problems. Since nothing phones home to check a license, copying those installers onto a USB drive or burning them to a Blu-ray or DVD is enough to keep a library playable long after the storefront disappears.

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

Ubuntu Now Has a Rolling Release Model! But Not For The Distro

Ubuntu is one of the most stable Linux distros out there, provided you're running its LTS release. Now imagine giving that up for a rolling release model. Feels exciting, right? Stop fantasizing then, as today's not the day that happens.

Instead, Canonical's latest announcement introduces a rolling release approach for the virtualization stack, which swaps the usual LTS cycle for a faster, six-month upgrade cycle.

Confidential computing is the driving force behind this move, as Canonical's Ijlal Loutfi emphasizes that the different pieces of the stack rarely arrive at the same time.

A processor might support a new feature before the kernel can expose it, before QEMU can handle it, before libvirt gives users a way to turn it on, and before the firmware and attestation tools are ready to make it actually usable.

How does this work?

Checking the installed virtualization variant with ubuntu_virt_helper.

The virtualization HWE stack has four parts. qemu-hwe handles the hypervisor and system emulation; libvirt-hwe covers virtualization management; edk2-hwe brings newer OVMF firmware for UEFI booting; and seabios-hwe does the same for BIOS compatibility.

It's the same approach Ubuntu already runs for kernels, just extended across the rest of the virtualization chain.

Switching to this is entirely optional, and during these first two years of Ubuntu 26.04 LTS, all four packages get refreshed every six months, but only after a dry run in an interim release first.

And stating the obvious, existing installations of Ubuntu will stay on the base stack unless someone decides to switch over to the new stack. A tool called ubuntu_virt_helper (different package name) handles that switch, since QEMU, libvirt, and firmware all need to move together as one unit rather than being swapped out piece by piece.

Why should you care?

This is basically Canonical admitting that confidential computing has outgrown the two-year cadence Ubuntu LTS was built around.

The virtualization HWE stack is aimed at anyone running confidential VMs on AMD SEV-SNP or Intel TDX, regulated workloads that need stronger isolation, AI inference that leans on confidential computing, or accelerators, and private or sovereign cloud platforms that can't just hop to Ubuntu's interim releases.

These workloads are moving faster than Ubuntu's own release schedule can absorb, and nobody running them is waiting two years for a point release to catch up with the ever-evolving silicon vendors.

Canonical is positioning this as a way to get LTS stability and newer hardware support at the same time, instead of users needing to pick one over the other.

Get started

Don't assume this is locked behind Ubuntu Pro. Every example in Canonical's instructional material runs on plain apt commands without requiring you to log in to some portal.

The most basic one is to install the helper tool:

sudo apt install ubuntu-helper-virt-hwe

The rest, you will have to figure out by going through the documentation and running the following command:

ubuntu_virt_helper --help

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

A GrapheneOS Privacy Feature Just Became the Basis for a Federal Indictment

An Atlanta resident, Samuel Tunick, is fighting a federal indictment that treats a privacy feature on his phone as evidence destruction. A grand jury charged him under 18 U.S.C. § 2232(a), a statute that covers destruction of property to block seizure by a government agent.

The root cause of all this was the deletion of a Google Pixel smartphone's contents during a border search, and the case itself sits in the Northern District of Georgia under case number 1:25-CR-499, before District Judge Eleanor L. Ross.

If Tunick is found guilty, the charge carries a fine, up to five years in prison, or both.

The coercion

On January 24 last year, the CBP placed Tunick into secondary inspection at Hartsfield-Jackson Atlanta International Airport as he returned from a trip to the Dominican Republic, putting him through several rounds of questioning and searches.

The officers started off by searching him, checking what he was carrying, and demanding that he fork over the passcode for his phone. All of this was reportedly done under the pretext of searching for CSAM.

He also asked for a lawyer multiple times, but the officers ignored every request, never read him his Miranda rights, and kept questioning him anyway. When he pushed back, they said it was "a whole different ballgame" at the border and that they didn't need a warrant.

Tunick eventually handed over a passcode.

But, the moment it was entered, the screen flickered blank a few times before the device rebooted itself, erasing its contents in front of the same agents who'd demanded access.

The motion filed by Tunick's lawyer stresses that his association with Defend the Atlanta Forest, an AGAAVE-labeled outfit, was the actual reason federal agents moved on him, not any crime.

Earlier, a Homeland Security agent had circulated Tunick's name and photo hours before his flight landed, flagging him for suspected terrorism activity, while FBI and CBP officers coordinated to set up the search.

Despite that, the government has never presented evidence tying Tunick to an actual crime connected to the movement.

What triggered this?

Tunick had what appears to be GrapheneOS's duress PIN/Password feature set up on his phone. When officers entered the passcode he gave them, it did what it was designed to do, wiping the device the moment the duress code was entered.

If you didn't know, this feature also triggers at any authentication prompt, not just the lockscreen, and covers every profile on the phone, not only the main one.

In a forum post that reads like a reaction to this case (though they never name it), GrapheneOS said people should carefully think through how they use the duress feature. And that wiping a device in an actual duress situation can carry physical or legal consequences of its own.

Guilty as charged?

Nope! Nothing's decided yet. A hearing on Tunick's suppression motion happened earlier this month, but the judge kept it open for more testimony before ruling on anything.

Written arguments are due through the fall, Tunick's side by September 18, the government's by October 9, and Tunick's reply by October 23. Until then, know that the five-year prison term attached to the charge is just the maximum the law allows, not what's actually coming his way.

As for my views, hearing about a citizen of a country getting worked over like this just to come home, only for it to end in a federal indictment months later feels like something you'd expect from a banana republic.

But that's how things go in the greatest nation in the world /s.

It makes you wonder how worthless the rights of the average Joe are, while people committing crimes that make your blood boil walk free. 🙃

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

I Really Want to Love This Markdown Editor, But One Thing Holds It Back

From the Git repo's README to blogs, Markdown is everywhere in the tech world in general.

I have been using Markdown for years. That's what I use for writing the articles here. While I often write directly in the CMS, I also manage personal notes, drafts and work on documentation in dedicated Markdown editors on my computer.

Over the time, I have used a number of Markdown editors on my Linux system. But I keep on exploring new ones, a force of habit, as it keeps me aware of the new tools in the field.

Recently, I came across a new Markdown editor called Ferrite. I tried and found that it mentions all the features I wanted:

• Folder view
• Dual pane
• Focused view
• Editor tool bar
• Git status
• Built-in terminal

There are many more features, like code folding, syntax highlights, mini-map overviews, diagrams, and more.

Basically, Ferrite is like an IDE but for Markdown (or should I say text) files.

🚧

It was later that I realized that the project, though open source, is 100% coded with AI. Read their AI workflow details here.
I'm adding this disclaimer because whether to use AI-generated code is a matter of principle for a lot of you.

Meet Ferrite, Markdown editor for developers

Written in Rust, Ferrite a text editor primarily for Markdown but with good support for JSON, YAML, and TOML files. Basically, various text files developers and devops deal with.

For markdown file, you can view it in raw mode (with synax), rendered view (only shows rendered markdown), and split view (shows raw text and rendered view side by side).

For other files, it just displays them with a mini-map overview and highlighted syntax.

There is zen mode for focused work.

Zen mode removes nice to let you focus on the text

Ferrite also allows you to create flowcharts, wire diagrams, mind maps etc.

In fact, Ferrite has a huge list of features. You can export files as PDF and HTML, run shell and Python codes from the editor itself, has a command palette, supports Wikilinks, can view PDF and CSV files and much more.

Basically, it's a Markdown editor specially created for developers.

Why I liked it

Lately, I found myself in situations where I had to edit technical documentation hosted on GitHub. The flow is standard. I fork the repo, clone it on my system, checkout to a new branch, make my changes, push it to my forked repo and then create a pull request to the upstream branch.

This is the usual code contribution flow, applies to collaborative documentation, too.

Now, since this is a dev-like workflow, a text editor that behaves like IDE is perfectly suited for this.

Built in terminal is useful for my workflow

Ferrite's built-in terminal gives me instant access to the command line for quick commit and push. It also shows the locally modified files if you are in a git repo.

For this kind of workflow, though I could use VS Code with extensions, it's an overkill. And I prefer to separate code and text files.

I used Ghostwriter, but it's a simple Markdown editor and I found myself switching between tools. This is when I came across Ferrite and it looked like it could be the perfect fit as it ticked (almost) all the checkboxes for me.

It's not perfect

Like most things in life, Ferrite is not perfect as well. I came across a few quirks after regularly using it for the past few days.

There is a dedicated button to sync the raw and rendered views when you are in the split view mode. This way you should be able to scroll on one side and see the impact on the side pane.

This feature works, but not perfectly. There is a lag that cannot be unnoticed.

0:00

/0:03

Sync issue between raw and rendered views

Then, it doesn't display images in the rendered view. This is a huge disappointment for me.

Take a look at the screenshot below:

Ferrite cannot display images?

I understand that relative path is crucial for image display in Markdown. But those paths were correct and the image was displayed properly in the Ghostwriter editor:

Ghostwriter displays the images correctly

Also, Ferrite has way too many features. It's like an IDE and if you have ever used an IDE you would know that IDE gradually become too complex with all kinds of settings and tweaks and busy interface.

Sometimes, simplicity also becomes a feature.

Should I use it or not?

Frankly, I did not notice the "100% AI developed" when I started using Ferrite last week. I liked what I saw, used it and fit very well for my current needs. I made notes, something I often do when I try a new tool, so that I can write articles and reviews on those tools later.

And when I started writing this article and went through the details, I learned that the project mentions explicitly that it is fully developed with AI.

That puts me in a dilemma. On one hand, it seems like a good piece of software. 1.7K GitHub stars are proof of its popularity. On the other hand, "100% AI" label is kind of offputting.

What would you do?

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

OpenUK Wants Britain to Stop Giving Away Open Source Creations

OpenUK recently published its AI Openness report, and buried inside the 40-page document is a big ask from the UK government. Build Britain its own foundation that holds code, governance, and standards the way the Linux Foundation (LF) does in the US.

If you are hearing that name for the first time, OpenUK is a UK-based (obviously) non-profit that advocates for open technology and is led by Amanda Brock. They first put out this call in a report titled "Making the UK the Home of Open Source," which was submitted to UKRI earlier this year.

The AI Openness report restates the case with added urgency this time.

The ask

Characterizing the proposed British flavor of LF as a National Foundation, the body, once formed, would hold repositories, standards, and datasets built with UK public money rather than watch that work migrate to servers and governance boards based elsewhere.

It would also handle training, community engagement, and event organizing. Those are areas that would otherwise need separate infrastructure, like an open source program office (OSPO) and a sovereign fund.

OpenUK frames this as a funding and governance gap more than a technology one.

They note that the UK ranks as Europe's top country in open source software and AI openness, yet it has no equivalent to the Linux Foundation, Germany's Sovereign Tech Agency, or China's Open Atom Foundation to show for it.

UK is bleeding open source

The non-profit didn't have to look far to prove its point, as MCP is the group's strongest example.

The Model Context Protocol, now the standard behind how AI models connect to outside tools and data, was created by two engineers in London. Anthropic backed the protocol and eventually donated it to LF's Agentic AI Foundation, alongside Block's goose and OpenAI's AGENTS.md specification.

In conversation with OpenUK, David Soria Parra, one of MCP's co-creators, said that they gave MCP away because they needed the standard to stay vendor neutral, free of trademark and licensing risk.

If the UK had an established foundation, then they wouldn't have lost MCP to the US. 🙃

Not the only ones

The European Commission has already shown off an initiative to break free from US tech dominance by moving towards an open European digital ecosystem. It would cover fields like cloud computing, artificial intelligence, cybersecurity, open hardware, internet technologies, and industrial applications like automotive and manufacturing.

Germany is closer to what OpenUK wants for the UK. Its Sovereign Tech Fund has turned into a government agency, and the report calls that "the right direction."

China has already proven the model works. Open source became a national pillar under its 14th Five-Year Plan, supported by a dedicated foundation called the Open Atom Foundation.

DeepSeek’s R1 showed how that focus pays off, leveraging open-weights and knowledge distillation to deliver frontier-level AI at a fraction of the cost.

OpenUK looks to garner interest from various public sector organizations across the UK while also aiming to collaborate with global experts, delivering the best proposal for their country as a result.

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

FireDragon Browser Swoops in With New Wings

FireDragon is the default browser on Garuda Linux, the Arch-based distro known for its polished KDE Plasma spins and reliability despite riding the bleeding edge. It has traditionally run on a Floorp base, giving it Firefox's extension support wrapped in Garuda's privacy defaults and Dr460nized branding.

Now the developers have flipped the playbook, changing its base and delivering a v13 release that's packed with many usability-focused improvements.

What's new?

This overhaul gets you a better search experience, where the default search engine is DuckDuckGo. It arrives alongside an expanded list of search tools that range from privacy-focused ones like Qwant, Brave Search, Startpage, and Big Tech options like Bing and Google.

Next is the improved onboarding experience, with the Welcome dialog now packing in one-click toggles for things you'd normally have to dig up in about:config.

Turn off the built-in password manager if you already rely on a separate one like Proton Pass (partner link), flip on ResistFingerprinting for tighter privacy at the risk of breaking sites, or switch on prefetching to speed up page loads.

New quick settings, search engine options, and pre-installed extensions (click/touch to expand).

Similarly, browsing speed sees a small bump with TLS 0-RTT now being enabled by default, cutting latency when reconnecting to sites you have already visited.

There's also the optional setting to enable prefetching (the same one as earlier), which starts loading a page the moment you hover over a link or downloads the next page in the background before you click it.

As for the other notable changes, v13 adds support for XDG Base Directories and now handles WebGL and DRM content through site permissions. It also drops Dark Reader from the default extension lineup, leaving Flagfox and uBlock Origin as the only pre-installed add-ons.

Should you ditch Firefox?

I spent time with FireDragon v13 to see how the new codebase holds up and whether it changes anything for someone deciding between it and stock Firefox. Most of it feels familiar, though there are a few rough edges worth flagging.

The quick-setup wizard, powered by the new Welcome dialog, left me a little disappointed as there's a lot of empty space on the page; however, the options themselves worked just fine.

Past that screen, the browsing experience feels like Floorp or Firefox with a Garuda twist to it.

Vertical tabs are where FireDragon comes closest to matching Firefox outright, with the layout looking nearly identical. The one kink is the title bar. Firefox hides it on Fedora Workstation (which comes with GNOME), but FireDragon shows an ugly one with no toggle anywhere in the settings to turn it off.

A bigger miss showed up with system theming. Firefox follows your system's dark or light mode automatically for both its interface and supported sites. FireDragon didn't do that for websites, even with the "Website appearance" option set to "Dark". I tested this across Mastodon, DuckDuckGo, and here (where you are reading the article).

Restarting the browser didn't help either. 😵

Enabling vertical tabs (left) and FireDragon Settings (right).

The dedicated FireDragon Settings page claws some of that back, with toggles for things like closing the browser window with the last tab, enabling middle-click paste, updating add-ons automatically, and additional controls for prefetching.

The Design tab lets you go further, letting you fine-tune any installed themes with a great degree of control over what gets shown and what doesn't.

So, should you ditch Firefox? If you're already on Garuda Linux, FireDragon v13 can be turned into a daily driver with some tweaking. If you're happily settled on Firefox itself, the theming bug and stubborn title bar make this a harder sell.

Get started

You can get the Dr460nized edition of FireDragon from Flathub for most Linux computers:

flatpak install flathub org.garudalinux.firedragon

FireDragon (Flathub)

For Arch users, there are four AUR packages on offer. One that is pre-compiled (should be faster to install), the second one that needs compiling, and the other two are the same but with Catppuccin theming (link1, link2).

People on platforms like Windows and macOS or those looking for alternative packages for Linux can visit Garuda Linux's GitLab instance. There's also a documentation page you can refer to, but keep in mind that it is a bit outdated.

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