Craving Hyprland But Don't Want to Configure It? Try Dank Linux

During your journey around the world of Linux, you might've come across riced-up builds that look and feel like something out of a sci-fi novel. And if you wondered, why can't I have this on my system?, then you wouldn't be alone.

Many of those builds have something like Niri or Hyprland sitting on top of a Linux distribution that plays nice with such heavy customization. But setting those up is a bit of work, and not everyone might be up for it.

That is where pre-configured distros and scripts like Garuda Linux, Omarchy, ArchRiot, etc. come into the picture. With this article, we will be taking a look at Dank Linux, a desktop shell suite that can transform your system into a slick Hyprland one.

Dank Linux: Hyprland Premium?

Okay, that might be a bit overstated, but using Dank Linux will make you feel that.

Here, you don't need to pay extra for Hyprperks, and instead, you get a tailored Hyprland desktop experience powered by DankMaterialShell (dms), which is a desktop shell built with Quickshell and Go.

It brings panels, a notification center, a lock screen, an app launcher, media controls, and automatic wallpaper-based color theming into one package.

Currently at v1.4.6 "Saffron Bloom", the MIT-licensed project is actively developed, with the installer supporting Arch Linux (incl. derivatives), Fedora (incl. derivatives), Ubuntu, Debian, openSUSE, and Gentoo (requires systemd), with both x86_64 and ARM64 hardware covered.

Installation was okay

There were a few steps in-between that are not shown here.

After setting up a minimal Arch Linux virtual machine, I ran the cURL script to get Dank Linux installed. The installer asked me to configure a few preferences, like the privilege escalation tool (I went with sudo), the compositor, and the terminal emulator.

I initially picked Niri as the compositor, but after installation, the session would hang on startup due to some bug. I tried a few fixes, but none worked, so I reran the installer and switched to Hyprland with Kitty as the terminal.

After entering my password and letting the installation finish, rebooting left me at a TTY login screen. The system didn't automatically boot into Hyprland, so I had to run the following command to get into the Dank Linux session:

hyprland

📋

Before diving in, here are the keyboard shortcuts you will need to get around:
- Super+Space opens the app launcher.
- Super+Q quits the active window.
- Super+Left Mouse moves windows around.
- Super+Right Mouse resizes them.

The desktop experience was lovely

Once in, you will notice that the installation is quite minimal, with only a limited set of applications shipped out of the box.

To get close to my usual Linux workstation setup, I had to separately install Firefox for browsing, LibreOffice for documents, Nemo as a GUI file manager, and VLC for audio and video playback.

Launching them was easy via the application launcher, with the top bar showing the active window title, a clock, a calendar, weather info, system resource usage, battery status, network connectivity, and quick access to notifications and settings.

Window tiling works cleanly, with windows snapping into a neat layout without any fussing around from my side. That said, the settings menu is where things get interesting in terms of customization.

You can pick a Material Design color theme, let the shell pull one automatically from your wallpaper, or set a custom one. Font changes apply across the shell from the 'Typography & Motion' section, and you can enable a dock if a top bar is not your thing.

The top bar itself is configurable, and you can even swap out the app launcher logo. Similarly, the quick access options are reorderable, so you can arrange them to match how you actually work.

Though this last one was a bit wonky during my testing, refusing to slot the buttons where I wanted them to.

Audio and video playback worked without any issues. I pulled up a YouTube video in Firefox, and it played back smoothly, with no tearing or stuttering worth noting given this was running inside a virtual machine.

What made it nicer was the 'Media' panel sitting in the top bar. It picks up whatever is playing and shows the title, the source, and a progress bar, along with buttons to skip, pause, or resume playback.

For documents, I grabbed a sample ODT file and opened it in LibreOffice Writer. Formatting text, rearranging content, and saving the file all worked as expected. Nothing surprising there.

Plus, it was good to see that the Wayland clipboard and app integration was working well during edit sessions.

The workspace switcher is another area where Dank Linux does well. You get 10 workspaces out of the box, and the switcher gives you a view of what is open across each one.

From the settings menu, you can choose what the workspace switcher indicator shows, whether that's workspace names, running app icons, or both, along with tweaking the overall appearance and enabling reverse scrolling direction.

Small stuff, but having all of that in a GUI menu rather than being buried in a config file can make a real difference in day-to-day use.

Get Started

On a supported distribution, you simply need to run the following cURL script to get Dank Linux:

curl -fsSL https://install.danklinux.com | sh

Though I highly suggest you go through the instructions for dankinstall to prepare your base system properly before making the switch.

Dank Linux

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

Proton Drive is Now Faster (And Getting a Linux Client Soon)

If you have been following Proton Drive this year, you know the pace of development has picked up. The developers have been busy rolling out a shared SDK across all their clients, and each update has introduced major improvements.

This week's update is the biggest one yet.

Two things have landed at once. Proton pushed a cryptography overhaul that makes file encryption a lot faster and quietly confirmed that a native Linux client is now in development.

A faster Drive experience

Illustration by the Proton Drive team.

According to Proton's testing, uploads are now up to 3x faster across platforms, and downloads are up to 2x faster.

Everyday tasks like Android photo backup and macOS file sync finish quicker, and the Photos section has been cleaned up too, with faster album loading and smoother timeline scrolling even in large libraries.

All of this is a result of Proton pulling together the work from their Mac, Windows, iOS, Android, and web teams into one integrated engine. Whereas earlier, every platform was running its own separate implementation, which meant development efforts were scattered across the board.

Now they all run on the same codebase, which means improvements roll out everywhere at the same time rather than platform by platform.

Encryption got a serious upgrade

Proton Drive has used OpenPGP to encrypt file contents since day one. The latest update moves to a newer version of that, and the key change here is that encryption now makes full use of the device's hardware.

The numbers shared by Proton make the difference clearly apparent. On mobile, a 4MB file that used to take 97ms to encrypt now takes 32ms. On desktop-class hardware, the same job goes from 12ms down to 3ms.

In practical terms, this means encrypting an HD video on your phone dropped from about 90 seconds to around 30, and on a desktop the same goes from around 12 seconds to 3.

Existing users are urged to update their clients to take advantage of these improvements.

Linux users, rejoice! 🎉

The most interesting bit of info in the SDK announcement is very easy to miss. Proton has confirmed that they are currently building a native Drive client for Linux, which is being put together from scratch using the SDK.

Earlier this year, the January SDK update had briefly mentioned a Linux client as something on the roadmap. This week's post is a step past that, with them confirming it is now in active development.

For years, many of you have been vocal about the lack of a native Proton Drive app on Linux, and if our comments section is anything to go by, it has been one of the most requested things from the Proton ecosystem.

The SDK is what is making it possible now, and building on it means the Linux client will not be playing catch-up with other platforms when it does arrive. If you haven't already, you can check out Proton Drive via our partner link below while supporting us in the process.

Proton Drive

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

Canonical Promotes Steam Snap to Stable on ARM64, With Plans to Rebuild It from Scratch Later

Canonical's Steam snap for ARM64 has been promoted to stable, nearly five months after a call for testing drew feedback from users across a wide range of ARM hardware.

The reason a snap like this exists at all is that Valve's Steam client for Linux is x86-only. To make it run on ARM64, Canonical bundled the x86 Steam binary together with FEX-Emu, a Linux usermode emulator that translates x86 and x86-64 instructions for ARM64 systems at runtime.

Snapcraft lists the stable release of the Steam snap for ARM64 now.

This stable release also introduces FEX's library forwarding feature (thunking) as a user-configurable option. Instead of emulating every graphics API call through FEX, thunking forwards OpenGL and Vulkan calls directly to the host system's native ARM64 libraries, which cuts down on emulation overhead.

Canonical has tested this release across three hardware families, all of which are said to have shown good performance across popular games. These include the NVIDIA DGX Spark and associated GB10 devices, Qualcomm Snapdragon laptops (Lenovo ThinkPad X13s, T14s, and Dell XPS 9345), and the Radxa Orion O6 and O6N.

Switch to stable

If you are already running the snap on candidate or edge and want to move to stable, run:

sudo snap refresh steam --channel=stable

They have also laid out a release cycle for the Steam Snap, with new versions first landing in the edge channel for experimental testing, then moving to candidate after around one to two weeks if no major issues surface. From candidate, they graduate to stable after another one to three weeks.

What's next?

Mitchell Augustin, who announced the stable promotion, wants to eventually rebuild the snap around Valve's native ARM64 Steam client and drop the FEX layer Canonical currently maintains on top of it.

Yeah, that native client is already out there, but quietly. ROCKNIX has already shipped it in their distribution, keeping both ARM64 and x86 launch paths available side by side.

Mitchell said he is keeping a close eye on it but is waiting for Proton 11 to exit beta first before making any moves.

For now, you can use the snap on your ARM64 device, and if you run into any issues or want to contribute to development, then the GitHub tracker for this app is the place to go.

---

Suggested Read 📖: Microsoft Just Brought Linux Commands to Windows

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

Linux Foundation Wants Open Standards for What AI is Actually Costing You

The Linux Foundation has been steadily growing its roster of projects and initiatives, with AI governance becoming an increasingly prominent part of that push.

Their latest push in this direction is a plan to launch the Tokenomics Foundation, a new program focused on open standards, benchmarks, and best practices for the economics of AI token consumption.

It will work in close partnership with the FinOps Foundation, which has been busy with efforts surrounding cloud cost management since 2020.

Why now?

The foundation says that token costs have been moving around. They dropped heavily through 2023 and 2025, then settled down, and new model pricing is climbing again.

Citing a research paper, they pointed out that global token usage is projected to grow 24x between 2026 and 2030, hitting 120 quadrillion tokens per month.

Separately, they also noted industry analyst projections of AI infrastructure investment crossing $1 trillion by 2027, with the inference market going from roughly $106 billion in 2025 to $255 billion by 2030.

None of this spending is easy to measure consistently today. Cached vs. non-cached tokens, input vs. output pricing, on-demand vs. reserved compute. Every provider defines and bills for these differently, with no neutral framework to compare them across vendors.

Having a standardized approach to all of this is precisely the gap the Tokenomics Foundation is looking to fill with its open standards and benchmarks.

What will it do?

The foundation will operate through a Governing Board that sets direction and allocates funding, alongside a Technical Committee responsible for the actual specifications and benchmarks.

The first confirmed deliverable is expanding the FOCUS specification, an open billing format that came out of FinOps, to cover token-based spending models. That would give enterprises a common schema for AI cost data regardless of which provider they are using.

Twelve organizations have thrown their support behind it so far, including Google Cloud, Flexera, KPMG, Accenture, Microsoft, Oracle, Salesforce, SAP, ServiceNow, Booking.com, IBM, and JPMorgan Chase.

The formal launch is at FinOps X in San Diego, from June 8 to 10, where the technical roadmap, initial working groups, partnerships, and upcoming conferences will be announced.

You might remember that the Linux Foundation took a similar approach with the Agentic AI Foundation late last year, pulling MCP, goose, and AGENTS.md under open governance before the agentic AI space had a chance to fragment further.

---

Suggested Read 📖: Tuta Joins The Euro-Office Umbrella

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

Not Kidding! Microsoft Just Brought Linux Commands to Windows Officially

Microsoft just shipped coreutils for Windows. Yes, you read that right.

ls. grep. cat. cp. find. The same commands that have powered Unix and Linux systems for over 50 years are now available natively on Windows, maintained by Microsoft itself.

In case you are not already familiar, GNU coreutils are the foundational utilities that every Linux and macOS system relies on for basic file operations, text processing, and shell scripting. They are the foundation of Unix computing. Tens of millions of scripts, pipelines, and workflows depend on them every day.

And now Microsoft is shipping and maintaining a build of them for Windows.

This is not WSL. You do not need a Linux subsystem running in the background. These "Linux commands" run natively on Windows, with the exact same flags and behavior as on Linux.

Microsoft's ultimate goal seems to make moving between Linux, macOS, WSL, containers, and Windows completely frictionless. Write a script once. Run it anywhere.

The Rust-based Windows coreutils is a work in progress

The package bundles uutils/coreutils (a modern Rust rewrite of GNU coreutils), findutils, and grep into a single multi-call binary. Every command supports standard flags. Same commands, same pipelines, no translation needed.

The project is still in preview and there are only a handful of commands. Since some commands have the same name in Linux and Windows, there is a possibility of conflict. Some don't fit in Windows environment.

Commands like dir, expand, more, paste, whoami conflict too directly with existing Windows built-ins. kill and timeout are unavailable due to Windows lacking POSIX signals. dd, dircolors, shred, sync, and uname were dropped as not useful on Windows. A longer list of POSIX-only commands like chmod, chown, chroot, mkfifo, id, who, and others are simply not applicable to the Windows environment. Who is surprised? Not me.

So, what commands are available as part of Windows coreutils then? The official GitHub repo does a better job at it:

Notice that there are separate columns for command prompt and PowerShell. Some commands would work in the default command prompt but not in the advanced PowerShell and vice versa.

Clearly, this is a work in progress and there should be more improvement on them in the near future.

Testing Linux commands on Windows

I booted into my Windows partition just to test it out. It's been months since I last logged in to the Windows and thus had to update the system with multiple reboots.

Sob story aside, I downloaded the .exe file for the Coreutils and installed it. Yes, these coreutils are offered in a single .exe file.

You can see a very brief demo of running some Linux commands in Windows command prompt. Some commands result in error as they are not supported yet.

A move for the agentic AI era?

See, the entire point of bringing Coreutils to Windows is to keep developers on the Microsoft platform. If they can use Linux commands and the tools their workflows depend on without leaving Windows, they have fewer reasons to switch to a Linux desktop. That is the same argument I made when WSL 2 was released years ago.

But this move goes beyond WSL, and in my opinion, it is not primarily aimed at developers, at least not in the direct sense.

Microsoft made several announcements at Build 2026 yesterday. One of them was bringing OpenClaw to Windows.

Now, OpenClaw is an open-source AI agent framework that lets autonomous agents run on your own machine. These agents rely on Linux commands, Python scripts, and similar tools to get things done. OpenClaw exploded in popularity earlier this year, so much so that people were buying Mac Minis just to run it locally.

These days, every operating system wants to be AI-ready. Development itself is increasingly happening through AI agents rather than purely by hand.

With OpenClaw coming to Windows, the ability to run Linux commands natively is no longer just a developer convenience, it becomes critical infrastructure for running AI agents.

That is what makes this announcement bigger than it looks. Microsoft is not just courting developers; it is positioning Windows as a serious platform for the agentic AI era.

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

Vim Classic is a Vim Fork for People Who Want Their Editor AI-Free

A Vim fork has arrived, and it exists because of AI. Drew DeVault, the developer behind SourceHut, announced Vim Classic back in March 2026 after becoming unhappy with the direction both Vim and NeoVim were heading.

His gripe was that generative AI had started creeping into their development, and he wanted no part of it.

The NeoVim side of that concern is the project's labeling of AI-assisted pull requests as "AI assisted 🤖," which has now stacked up a fair number of requests, many of which have already been merged.

With Vim, the situation is a bit murky. Drew points to a GitHub issue where community members suspected one contributor of using LLMs, but a Vim maintainer had already pushed back on those accusations.

Anyhow, Vim Classic has received its first-ever release, so let's see what it has to offer.

🚧

Drew warns that Vim Classic is meant for early adopters. Not for people looking to daily drive it.

A classic Vim experience

Screenshot of the website because building from source is ☠️.

Based on Vim 8.2.0148, Vim Classic predates the Vim9 script entirely. This was done deliberately to keep the maintenance burden manageable, stopping at the last patch before the script was introduced.

As a result, some Vim plugins that rely on Vim9 Script will not work with Vim Classic.

From that base, select patches have been backported from upstream, mostly addressing CVEs discovered after 8.2, alongside some bug fixes and original patches to keep things building on modern toolchains.

DeVault is also upfront that not every applicable security patch has been confirmed as backported, so some CVEs may have slipped through. The project is currently recommended only for early adopters comfortable with that uncertainty.

In addition, the charityware model carries over from Vim, with this project continuing to support the children of Uganda (albeit via a different charity) that Bram Moolenaar, the creator of Vim, endorsed.

📋

The original ICCF Holland charity was dissolved following his passing, with its mission carried forward by Kuwasha.

The packages

Vim Classic 8.3 is currently available as a source tarball from SourceHut (direct download). You will also find the release tarball and its PGP signature, signed with DeVault's public key, up on the project's refs page.

For the source code, head to the homepage of the SourceHut instance for Vim Classic.

Vim Classic

---

Suggested Read 📖: KDE Linux is Coming Along Nicely

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

I Tried This Open Source ChatGPT Alternative on Linux, But Went Back to Ollama

I may hate AI slop but I am not a AI hater. I have found decent use of the AI tools and I try to include these tools in my workflow wherever it makes sense.

While mainstream LLMs like ChatGPT and Perplexity have decent free offering, they leach on the user data. "If you are not paying for the product, you are the product".

That's why I am loving the idea of exploring local AI and I have spend my fair share of time experimenting with LLMs that can be run on normal systems.

Recently, I discovered Jan AI. It is a polished, genuinely usable desktop app that runs entirely on my machine. In fact, I once tried replacing Ollama and llama cpp with Jan AI, but later changed my mind.

I'll explain why I switched back to Ollama in the later sections. First, let's learn about Jan AI.

What is Jan AI?

Jan is a free and open-source desktop application that lets you run various large language models directly on your own hardware. You can think of it as a self-hosted, offline-capable ChatGPT, except the model runs on your CPU or GPU, and no data ever leaves your machine.

The project is developed by the Jan.ai company, and the source code is available on GitHub under the AGPL-3.0 license. It's built on top of llama.cpp under the hood, which means it can run quantized GGUF models efficiently even without a dedicated GPU.

What I found impressive is that Jan's desktop application is built using the Tauri framework instead of Electron JS, which gives it a good performance boost and I think eats less RAM, too.

A quick catch, you still need plenty of RAM for running your local LLM.

The app supports Linux, macOS, and Windows. I used it on my Linux machine.

System requirements

Running a local LLM with Jan AI does require decent hardware. Here's what to realistically expect:

• 8 GB RAM minimum. It's enough for 7B parameter models at 4-bit quantization (Q4_K_M). You'll notice slowdowns with other applications open. 16 GB RAM is the sweet spot. It can comfortably run 7B models and lets you experiment with 13B models.
• GPU acceleration is optional but makes a big difference. Jan supports NVIDIA (via CUDA), AMD (via ROCm), and Intel Arc. If you don't have a compatible GPU, CPU-only mode works, but it's significantly slower.
• Disk space models range from around 4 GB (7B, Q4) to 8 GB+ (13B). Download only what you need.

📋

I've been running Jan on a machine with 16 GB RAM and no discrete GPU, and a 7B model gives me response times that feel somewhat usable.

Installing Jan AI on Linux

Jan offers multiple installation formats, including .deb and AppImage, but the AppImage is what I'd recommend for most Linux users. It's a single self-contained file that runs on virtually any distro without touching your system packages or requiring root privileges for the app itself. It requires no dependency hell. It's just made to work.

Download Jan AI from GitHub

I am not going in the details but if you need help, refer to this guide to use AppImage on Linux.

When you run Jan AI for the first time, you should see an interface like this:

Jan application interface for running local AI models

Downloading models and putting Jan to work

A freshly installed Jan is essentially an empty shell capable, but waiting. The first thing you need to do is grab a model. Think of it like the app is the frame and the model is the brain.

Finding your way to the model hub

Click the Hub in the left sidebar. This is Jan's built-in model library, a curated list of open-source models you can download with a single click.

There are dozens of models with names full of numbers and letters like Q4_K_M or IQ3_XS.

Jan AI application's model hub

Before I recommend which ones to pick, let me quickly demystify that alphabet soup because I spent an embarrassing amount of time confused by it when I first started.

What does Q4_K_M actually mean?

Every model name carries a quantization tag. Quantization is how a model's original full-precision weights get compressed to fit on consumer hardware. Here's a practical breakdown:

• Q4: 4-bit quantization. The most common choice. Roughly 4 GB for a 7B model. Fast, memory-efficient, and quality holds up well for everyday tasks.
• Q8: 8-bit quantization. Nearly full quality, but needs about twice the RAM. Worth trying if you have 32 GB or more.
• K_M: The specific compression method (K-quants, medium variant). Generally, the best balance of speed and quality within the Q4 family.
• XS (Extra Small): This is the most aggressive compression. It results in a file size that is slightly smaller than a standard Q4_K_S

💡

If you have 8–16 GB RAM, stick with Q4_K_M. If you have 32 GB+, try Q8_0 for noticeably sharper outputs.

The 3 LLM models I tested

I am using an AMD laptop with an integrated GPU. I settled for CPU interference for local LLM models because enabling RoCm (Radeon Open Compute) is a hectic task, based on my research. It requires 25-30 GB of disk space.

For those of you who aren't familiar with what AMD ROCm is, it's the answer to NVIDIA's CUDA. Basically, when you run a local LLM, the heavy math, such as matrix multiplications across billions of parameters, can be offloaded to a GPU instead of the CPU.

RoCm lets software like Jan AI, PyTorch, or Llama.cpp talks to AMD Radeon GPUs to do that same heavy lifting. Without it, Jan falls back to CPU-only mode, which works but is significantly slower.

For this article, I settled on three models that cover a solid range of use cases. I asked the same question to each model - "What can you do"? Here's what I found:

Gemma 4

I don't lie. The performance wasn't superb, only 5 tokens per second.

Gemma 3

The performance was bad than the Gemma 4 2B model. It was only 3 tokens per second. I think you can use the Gemma 3 2B model variant to achieve comparable performance.

Jan

Yeah! Jan offers its own AI model. I used the Jan-v3-4b model to test. It comes with 262K context length. It can follow up instructions and do some light coding tasks.

Features I liked in Jan AI

Let's see a few features that I liked in this open source AI tool.

Unified Interface for Local and Cloud LLMs

Jan can act as a unified interface for local and cloud LLMs, instead of jumping from Claude to ChatGPT and then Gemini. You get to talk to your favorite LLMs within a single interface.

Though directly interacting with Cloud LLMs takes away your privacy, you can still use Jan AI as a unified interface to interact with any models on HuggingFace, Groq, Gemini, Qwen, Mistral, and Claude with the respective platform's API.

Configuring cloud LLM provider like Groq, Gemini, OpenAI, Mistral and OpenRouter within a single unified interface of Jan

I'm especially in love with the Groq and Cerebras API. These platforms provide fast interference.

If your model provider is not in the list, you can still add OpenAI-compatible models to it.

To add, click on the plus icon next to "MODEL PROVIDERS". It'll ask for a name. Enter the name and then set the BASE_URL and API Key provided by your LLM platform.

Keeps your chats organized

Jan offers the functionality to organize chats per project.

Tailor Jan for Custom Experience

You can edit the system instruction. It's kind of making LLM behave like a specific expert.

Local API Server

It comes with a local API server. You can start the server by going to Settings -> Local API Server.

Use it as a tool to download AI models for Llama.cpp

Models downloaded with Jan AI application are completely compatible with Llama.cpp CLI. You can use Jan as a downloader tool and then run the downloaded AI model with llama-server a command.

Jan CLI

Jan offers a CLI interface to interact with as well.

My honest opinion on using Jan AI vs Ollama

Thanks to the developer involved in building the Jan AI app. It provides a nice GUI interface to interact with LLMs. On the contrary, I see some improvement scope for the application.

Ollama vs Jan AI application

The major one is with the local LLM inference time. I tested the same model, and what I found was that Jan AI provided slow inference time as compared to Ollama on the same hardware. Ollama produced a response at a rate of 6.62 tokens/sec while Jan AI produced a response at around 5 tokens/sec.

On the second test, Ollama reported 7.35 tokens per second while Jan AI responded at 3 tokens per second. Also, I tried Llama.cpp for the same Gemma 5 E2B model with 3.97 tokens/sec.

The secondary issue is Jan application often freezes your system. I agree, running LLM models takes significant RAM memory, but there are a couple of attempts I faced where giving a prompt with the Gemma 4 E2B model freezes my system. I haven't faced any similar issue with Ollama. That's why I kept Ollama and Llama.cpp for my local AI model inference.

Who is Jan AI actually for?

After spending time with it, I'd say Jan AI fits a few kinds of people particularly well. One thing I need to justify here, although in my tests, Jan struggled to give me more than 5 tokens per second in CPU mode, running it on a system with modern GPUs like Radeon GPU, Intel Arc, Nvidia 4050, you may get to see a huge boost in performance, especially with tokens per second. You could achieve around 13-15 tokens per second.

Privacy-conscious users who want AI assistance without feeding their conversations to a corporation. Lawyers, journalists, healthcare workers, and anyone handling sensitive information fall into this category.

Developers who want a local AI backend for their tools. The OpenAI-compatible API makes it drop-in compatible with a surprising number of existing integrations.

Linux enthusiasts who simply prefer FOSS software and want to own their stack. The fact that it's AGPL-licensed and actively developed is a big plus.

People on a budget. It comes with no API costs or subscription. You run it on hardware you already own.

It's not for everyone. If you need GPT-4 level capability for complex reasoning tasks, you'll still feel the quality gap compared to frontier cloud models. But for writing assistance, summarization, brainstorming, and everyday tasks? A well-tuned 7B or 13B model gets the job done.

The bigger picture

Local AI is no longer a hobbyist experiment. The AI models like Gemma 4, Gemma 3, Granite, Jan AI model, and SmolLM2 have gotten small enough that a standard laptop can run something genuinely useful. Tools like Jan have made the setup approachable enough that you don't need to be a machine learning researcher to get started.

Jan AI won't replace cloud services for everyone. But for a growing number of Linux users who care about privacy, cost, and control, it's become a daily-use tool. I'd encourage you to try it. Download it, grab a 7B model, and see how far it gets you.

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