OpenSearch Is Done Being Called "the Elasticsearch Fork"

I sat down with Bianca Lewis of OpenSearch at Open Source Summit India, right after the project's second OpenSearch Con in the country. Bianca Lewis is the executive director of the OpenSearch Software Foundation.

OpenSearch started life in 2021 as a fork of Elasticsearch, born out of Elastic's move away from an open source license. Five years on, I wanted to know how much of that origin story still holds, and how the project sees itself now that it's an AI data infrastructure layer with its own roadmap and its own community.

We covered a lot of ground: whether OpenSearch is still tethered to Elasticsearch in any way, why ELK Stack remains the more recognizable brand among young developers, how agentic AI fits into the platform, and an uncomfortable but necessary question about what happens when vendor-backed open source projects go proprietary.

📋

It was a face-to-face conversation and it is lightly edited for clarity. And since it was not a straight forward text interview, the answers are more conversational in nature.

Five years in, is OpenSearch still a fork of Elasticsearch, or has it become a product of its own? Does it still pull in any downstream changes from Elastic?

Bianca: That is a great question, and the answer, very simply, is yes, it's an independent project. It's a completely independent project now that began as a fork, as you correctly said, and in the early days the two were very, very similar. Today the focuses and the strengths have become very different, and today they are completely independent projects. I think the only commonality is that users can still use both platforms for similar kinds of use cases.

Explaining OpenSearch to the average Linux user

OpenSearch is enterprise-focused, but how would you explain it to a home labber or self-hoster who's never heard of it?

Bianca: Well, firstly, of course OpenSearch is an AI infrastructure layer for enterprises, but because it's on an open source platform, free and easy to use and adopt, people making new startups, entrepreneurs, developers, and everyone else find it very easy to get started. Download it, it's free to use, all the features are open and available, and they can join very easily a community of thousands and thousands of people to get up and running.

So it's not just enterprise-focused anymore, it's for anyone and everyone. Whoever's requirements fit it, OpenSearch is for them. I don't think it was ever built to just be for the enterprise. The startups of today are the enterprises of tomorrow.

"The startups of today are the enterprises of tomorrow."

The ELK Stack brand problem

ELK Stack is still the more recognizable brand in observability and search. How does OpenSearch compete with that brand recognition among young developers?

Bianca: There is no doubt that Elastic, Elasticsearch, and Logstash and Kibana, which make up ELK, have been around a long time, and that's obviously where the fork came from originally. I hope that after five years of OpenSearch developing as an independent and powerful project — 1.7 billion downloads later, 400 individual companies contributing, more than 3,000 contributors, and 15,000 OpenSearch stack users — the differentiation in young developers' minds is becoming clearer just from the sheer weight of numbers.

I think there are two distinguishing factors. The first is philosophy — how developers want to build their technology stacks conceptually and into the future. Elastic, who owns ELK, even though the license is now back to open source after they closed it, is still owned by Elastic and is open core. That means if a young developer wants to build on Elasticsearch and use the ELK stack, they can use the core version for free, but for any more advanced features or support they're going to have to pay and be tied into Elastic. Developers who want to build on a platform that's fully open, where you get the whole thing for free and can choose whether you want support or hosting when you're ready, have that choice with OpenSearch. It's a different philosophy.

The second layer is that the two platforms have grown along different technological paths. Every platform in this space will say "we're a millisecond faster at this," or "we support this use case better," and that's all true — no platform can honestly say it's the best at everything. But OpenSearch is really good at a lot of different use cases that unify the data layer, and because it's the only alternative that isn't just open core, it's making young developers distinguish OpenSearch, hopefully much faster than ELK or any other platform.

Observability, complexity, and cost

Observability stacks are getting heavier, more expensive, and more complicated. What is OpenSearch doing about ease of setup and cost?

Bianca: Those are two very valid questions, so let me answer them one by one.

On complexity: the advantage of proprietary vendors has always been that on day one it's easy — you buy it, it's off the shelf, it works, and you get support. With an open platform, you build it on day one, and you get the benefit on day two, three, and four because it's customized to your needs and you're not dependent on a vendor. But getting started on day one is a very valid point. Because of that, we've recently launched something called Launchpad, which lets you eailylaunch an observability stack, a search application, or any other OpenSearch application, because OpenSearch isn't just observability, there's also search, AI applications, and security monitoring. All this takes a few minutes, and we encourage developers to ask the community if they get lost, even though the documentation is all there. I believe the ease of setting up OpenSearch has been addressed incredibly well and quickly.

On cost, it's a more complicated question. I can tell you OpenSearch is free, but in real life nothing is ever truly free because you still have to run it on infrastructure and manage it.

What OpenSearch does do is make everything cost-effective. Take observability: in the old days, we had to have it because if something in our infrastructure broke, we had to solve it — we couldn't afford downtime — but nobody wanted to pay for it because it was seen as a cost center.

Today the whole language has changed, because OpenSearch gives you a unified view of the context of your data, which is much more cost-effective than doing log analytics, traces, and metrics separately with tools like Grafana and Prometheus, where everyone looked at the data differently and root-cause analysis took five weeks to put the pieces together.

Today it's all in a single pipeline into OpenSearch — you see it all together, through different lenses in the same view, and you can automate resolutions. You can use models and AI to interrogate that data, automate resolutions, and use your observability stack for more than troubleshooting — for company-wide SLOs, understanding acceptable error rates, and understanding cost.

We're in the token economy now, so we can add cost information into traces and logs and understand accurately how much each service is really costing us. Observability isn't just "pay for troubleshooting" anymore — it's become easier to use and a driver of business imperatives.

AI-agent readiness

How AI-agent-ready is OpenSearch, for someone building a project that leans heavily on agentic AI?

Bianca: In the 3.5 release — we've just released 3.7, so we're two minor versions past that — agentic AI became generally available in OpenSearch, and since then it's become a central theme of how people run their search and observability stacks. I think we're ahead of almost any other platform in the world on fully integrated agentic AI.

As you spin up AI agents, OpenSearch is model-agnostic, so you can use any AI model you want. If it's for a search use case, you can monitor those AI agents with the same platform — monitor the trace of the agent, see which services it's calling, what the costs are, and make sure it's doing the right thing. At scale, when you're running 100,000 queries a minute, we can almost let AI monitor AI for security, safety, and compliance.

AI brings scale and the ability to do things quickly. We don't have to work sequentially anymore. But data without context is just data, it's noise. You need a platform that can recall it and spin up AI agents, you need the data underneath it, and you need the agents to talk to each other to perform tasks but without context, all of that is garbage at scale. OpenSearch has built in some features to address this: short-term agentic memory, so an agent remembers the context of what it was asked over the last week or two, and in 3.7, long-term agentic memory as well, which gives us the context we need to take accurate actions on the data. It's already generally available.

AI data layer vs. traditional search

Is OpenSearch now an AI data layer sitting on top of a traditional search stack, or have the two fully merged?

Bianca: I think ultimately OpenSearch will be looked at in a couple of layers. OpenSearch is the application level, and the application level sits on top of an infrastructure that supports the architecture of the application.

What OpenSearch gives you is that it doesn't tie you into any one vendor's choices. You can have that AI infrastructure layer but choose your own infrastructure. You can self-host, or go to one of the hosted services, like our OpenSearch service on NetApp, Oracle, and AWS and choose whatever fits your model. In terms of features and how things run with agentic AI, we don't really say this works better or worse than that. We say everything works and works really well, and with OpenSearch you retain control over how you want to build it, without being tied into any one approach.

On business-source licensing and the Linux Foundation model

This is a bit of an uncomfortable question, more about the Linux Foundation model in general than OpenSearch specifically. MariaDB, Redis, and Elasticsearch all moved from open source to business-source or server-side licenses at some point, largely to protect their business from hyperscalers who weren't contributing enough but were taking their enterprise customers. Then the Linux Foundation and companies like Amazon fork the original project, as happened with Terraform and OpenTofu, and grow it as the "true" open source version while the original gets left behind. Is there an injustice in that, toward the original projects?

Bianca: I think it's a really great question. I don't ever judge a vendor for deciding to close-source or open-source a project. But without intruding into the particulars of how Elastic or AWS felt at the time, which I can't speak to, I can share a personal viewpoint.

If a vendor is the owner of an open source project, to me that open-core label is simply a go-to-market strategy to get users in and then sell services, support, and enterprise capability. It's not what we'd call vendor-neutral. Building a wide community on a vendor-owned open source project is always tricky, and that's why Mongo, Elastic, Redis, and a few others reached a point where the situation became a threat — the go-to-market had been really successful, they'd built a community, but the biggest customers weren't converting.

I find it interesting that Elastic changed back to an open source license after closing it — because they were losing the community, but they'd closed it because they were losing enterprise customers. They were fine with small players using the free product but wanted the big-money customers. The challenge is that often you want your cake and to eat it too. Once you build your brand on community involvement and then tell the community you're closing it, even if you reopen it later, a lot of the community will just say "thanks, but no thanks."

That's the beauty of the Linux Foundation model. It's a nonprofit that nobody owns, and profit isn't the motive. Yes, there will be cases where hyperscalers fork a project. I think it's important to understand that once they fork it and give it to a nonprofit like the Linux Foundation, they give up ownership. They don't own OpenSearch anymore. They could fork it again and keep something in-house, anyone can always do that, but OpenSearch itself can never be closed now, because the Linux Foundation owns it.

OpenSearch itself can never be closed now, because the people that own it is the Linux Foundation.

It also helps to look at where each company actually makes its money. Take Elastic. They make money selling Elasticsearch licenses, whether self-hosted or on the cloud, so it makes sense for them to gate advanced features behind a license, because they have to survive as a business and answer to shareholders.

Hyperscalers like AWS, Microsoft, Google, IBM, and Oracle make their money from selling compute and infrastructure, not directly from the application. Carrying the burden of growing and innovating an application takes away from their core focus of selling infrastructure, so it makes business sense for them to let the community develop the application while they focus on providing a great service to run it, and put their money where they actually make money.

That's the subtle reason hyperscalers are so eager to support Linux Foundation projects. It lets them focus on where they make money, and it guarantees these projects stay open, available, and well-maintained rather than becoming orphaned.

Ultimately it takes time for a project's original founder to say "now we can let the community manage it." What that actually means is that over the years, instead of maintaining the application with a full-time in-house engineering team, the founder becomes one of the companies contributing to a shared engineering effort. You get all the benefit, but the innovation and cost become shared, and the community retains the choices, which is always good for business.

Certifications

Does OpenSearch have plans for a certification track, like Kubernetes has with the CKA?

Bianca: Yes, we've actually recently announced that. The way we're doing it is quite unique and exciting for the open source world. We've already released the first form of learning content, and in a couple of months we're going to release an OpenSearch competency course that carries a badge of competency you can put on LinkedIn.

On top of that, we're going to do the OpenSearch competency certification proper, and based on that certification, we're doing accreditations for different vendors and companies. The follow-up to that is specialist certifications. Since OpenSearch is used across quite a few use cases, we'll have competencies in observability, search, AI applications, and security monitoring. And to renew your certification, instead of retaking the same test every couple of years, as long as you're advancing to more advanced certifications you keep your original qualifications. We want people to grow and advance within OpenSearch.

The biggest misconception about OpenSearch

What's the one thing that most people get wrong about OpenSearch?

Bianca: There are so many things people get wrong about OpenSearch, but I think the biggest one is not recognizing that, as an AI data infrastructure layer, OpenSearch is the only cloud-native, AI-native platform in the world that's truly open source and vendor-neutral. I don't know if people really understand that.

OpenSearch is the only cloud-native, AI-native platform in the world that's truly open source and vendor-neutral.

Maybe if it were named something like "OpenSearch AI" or "OpenAI Search," it would be more recognizable.

Bianca: Yeah because people often equate it to "how does it compare to Elasticsearch?" But conceptually, you can't really compare the two. They'll say "it's like the AWS service," but that's just a vendor who's a member and provides a service on top of it. The platform runs completely independently, within a community that's truly open source. It's not just an AWS project anymore; it's a truly independent, community-owned observability stack.

---

OpenSearch's 3.7 release, with long-term agentic memory, is already out, and the project's competency certification track is expected to roll out over the coming months. You can find the project's documentation, downloads, and community channels at opensearch.org.

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

Illinois Just Told Every Operating System to Start Reporting Your Kid's Age

Illinois has become the latest U.S. state to pull operating systems into the age verification pool. Governor JB Pritzker has signed HB5511, the Children's Online Social Media Safety Act, putting forward a new age verification framework for every device sold or used in the state.

The bill imposes age check on "covered manufacturers," a category that lumps device makers, operating system providers, and app stores together.

Protect the children!

By January 1, 2028, these manufacturers have to build an interface at account setup asking a parent or account holder for the child's birth date. That date is then converted into one of four age brackets: under 13, 13 to 15, 16 to 17, or 18 and up.

The law also stipulates that all transmitted digital signals have to be encrypted.

Applications can then pull that bracket through an API once a user downloads or launches them. Once they get a signal marking a user as a minor, they're legally treated as having "actual knowledge" of that.

Once flagged, apps have to turn on a set of safety settings. Feeds get restricted, profiles get hidden from adult strangers, messages from adults get blocked, precise location gets masked, and notifications go dark between 10 PM and 7 AM.

Parents can override these defaults for their kids, and minors over 16 can do it themselves too.

Apps have until July 1, 2028 to start requesting these signals, and violations can cost up to $50,000 each, enforced by the state Attorney General. Device manufacturers and apps acting in good faith aren't liable if a signal turns out wrong.

Rep. Jennifer Gong-Gershowitz led the bill through the House, with Reps. Margaret Croke and Janet Yang Rohr as chief co-sponsors, and more than a dozen others signed on. Sen. Willie Preston carried it in the Senate alongside Sens. Robert F. Martwick, Mary Edly-Allen, and Adriane Johnson.

It passed 82-27 in the House and 57-0 in the Senate before clearing final concurrence unanimously.

Open source exemption where?

Illinois isn't the first state to try this model. Colorado's SB26-051 and California's AB-1043 both rely on the same OS-level age signal setup; apps request it, and the device answers.

Both of these started off without any concessions for open source platforms (e.g., Linux).

Colorado's SB26-051 originally applied to every operating system and developer without exception. System76 founder Carl Richell worked directly with state lawmakers to change that.

The bill picked up language exempting operating systems and developers distributing software under terms that let anyone copy, redistribute, and modify it freely. It also added a clause blocking platforms from locking down modified versions.

California's AB-1043 had the same gap. Assembly Member Buffy Wicks, the same lawmaker who wrote AB-1043, introduced AB-1856 to fix it. After several rounds of edits, the amended bill redefines "operating system provider" to exclude anyone distributing software under those same open license terms.

Illinois has none of this. HB5511's definitions for "covered manufacturer" and "application store" stay just as broad as these bills were before their amendments.

My two cents

Well, folks, we sure are getting close to someone's wet dream of having a dystopian hellscape where people don't have control over their computers, food, or water.

On the one side, you have these so-called "bipartisan" bills passing through without much hindrance under the guise of protecting children, and then you have the island-class cretins who still haven't been prosecuted.

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

Proxmox Virtual Environment Officially Runs on ARM64, But Your Raspberry Pi Isn't Supported Yet

Virtualization is basically load-bearing infrastructure for any serious data center in 2026. Enterprises lean on it to run more workloads on less hardware, isolate services cleanly, and keep uptime high without buying a rack of extra servers.

Proxmox has built a name for itself in this space over the years with its range of products.

Proxmox Virtual Environment (VE) handles virtualization, Proxmox Backup Server covers data protection, and Proxmox Datacenter Manager ties it all together as a solution for managing distributed infrastructure.

All of it ships as open source software too! 🤌

Now, they have announced a major development for Proxmox VE, their flagship virtualization platform.

Proxmox VE on ARM64

A stand-in image of Proxmox VE 9.2.

Yep, that's the highlight move. Sitting alongside its existing x86-64 builds are the new ARM64 images that have brought official support for the Arm platform.

Proxmox says the new images follow the same codebase, release lifecycle, and support window as x86-64, while running on Debian 13.5 "Trixie" with Linux kernel 7.0 and additional components like QEMU 11.0, LXC 7.0, and ZFS 2.4.

Likewise, storage gets similar improvements with ZFS 2.4 and Ceph, two of Proxmox VE's core storage options, carrying full feature parity with the x86-64 build.

Though you should know that officially supported hardware is currently limited to the NVIDIA Grace and Vera platforms. Proxmox has also validated the Arm64 build jointly with NVIDIA and Supermicro, testing specifically on Grace Hopper Superchip servers.

Other UEFI-based ARMv9-A hardware gets best-effort support, and Proxmox says ARMv8-A "generally works too." What's not supported is that Raspberry Pi lying on your desk, or really any other devicetree-only single-board computer, like an Orange Pi or a Radxa ROCK board.

Don't think that ARM64 support is stopping at Proxmox VE; the developers are already running internal test builds for their other offerings, with Proxmox Backup Server being one of the examples given.

However, which one gets prioritized depends on their enterprise customers' needs.

Get started

Seeing that ARM64 as a platform has matured so well along the years, and more and more workloads have shifted to this over x86-64, this move doesn't really come as a big surprise to me.

Proxmox didn't ship this as an experiment either. It launched this with full support from day one. This, to me, is a company that saw where the market was headed and adapted accordingly.

Anyhow, Proxmox VE for ARM64 is available now as a free download, either as a bare-metal ISO image or through package repositories alongside the existing x86-64 builds.

Enterprise users get access to the pve-enterprise repository too, same as on x86-64, with Proxmox recommending it for production deployments.

You can grab the Arm64 ISO installer directly, dig into the documentation for setup details, or browse the source code repositories if you want to see what's under the hood.

Proxmox VE

---

Suggested Read 📖: Our informative mini-course that covers everything from installing and upgrading Proxmox to using it.

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

Nobody Touched This Linux Driver for Years, Until AI Started Poking Around and It Got Removed

Greg Kroah-Hartman just deleted a Linux driver that hasn't mattered to anyone in years.

The reason for removal wasn't a bug report or a user complaint. It was AI agents poking around dead code and turning up findings nobody asked for.

That sounds like another "AI is reshaping open source" piece. It mostly isn't. This driver was already on its way out, Moxa said so years ago. What changed is the removal finally happening at a time when AI is scraping away at the kernel codebase.

What's happened?

On August 3, GKH sent a patch to the linux-serial mailing list removing drivers/tty/moxa.c entirely. That's the Moxa Intellio family multiport serial driver, code that's been part of the kernel since 1999.

The patch strips out 2,137 lines of driver code, plus the Kconfig and Makefile entries that reference it. In total, 2,148 lines of unused code are gone.

GKH says that:

This is a very old driver, and no known hardware is still around for it, and the company says they do not need it anymore, so let's remove it as the LLMs are starting to poke at it and find "interesting" things which will just waste everyone's time given it's not actually used.

While keeping the door open for anyone who actually still needs it, noting that the driver could return down the line, just built "in a more 'modern' way."

Some context

Moxa isn't some obscure or defunct outfit that used to be cool back in the 90s. It's a Taiwanese company that makes industrial networking gear and serial cards for factories and railway systems.

The Intellio series was an older PCI serial card lineup from their catalog, not a piece of consumer hardware you'd find lying around in people's attics.

While software support was promised through 2023, the hardware itself was discontinued way back in 2017. According to an email Moxa's Ray Chen sent Jiri Slaby back in 2021, the company had no plans to keep the Intellio line alive any longer.

Jiri, who has maintained parts of the kernel's serial driver code for years, floated marking moxa.c as broken or dropping it outright.

Nothing happened until May 2026, when a separate patchset reorganizing the tty subsystem's directory structure brought the topic back up. Crescent Hsieh from Moxa confirmed both the hardware and its software support were fully phased out and even offered to help write the removal patch himself.

That gap isn't unusual on its own; kernel patches sit in queues all the time. What's notable is what finally moved it (AI poking holes).

Where AI comes in

So saying that "AI is deleting kernel code" would be overstating what's actually happened. The Moxa folks had already signed off on removal in May. GKH didn't act until August, three months later.

What the AI did was start poking at 27-year-old code that everyone already agreed was dead, bringing up findings on hardware nobody has left to test against.

If you are used to working with AI agents, then you know that scanning old, unused code doesn't always produce genuinely new work. Sometimes it just produces enough annoyance that maintainers have to act to nip it in the bud.

This change landed minutes before GKH drew a different kind of line, rejecting LLM-generated patches for the kernel's staging tree entirely. So take note of this, while AI isn't writing much of the Linux kernel yet, it's already influencing which parts of it get tossed out.

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

After Nearly a Decade of Distro Hopping, I Realized It Was Never About the Distro

For years I thought I had strong opinions on Linux distros. Ubuntu was too heavy or it felt. Arch was too fiddly. Kali was surprisingly practical (don't judge me).

Looking back at nearly a decade of distro hopping, I realize I had the whole thing wrong.

It was never really about the distro. It was about what desktop environment sat on top of it.

My Linux story starts with Mint

The first Linux distribution I ever installed was Linux Mint Cinnamon, around 2017. Linux Mint is what made me think Linux was actually livable. The desktop made sense. Things were where I expected them to be. It was Ubuntu underneath, sure, but that's almost beside the point; what mattered was that the experience felt considered.

I didn't move to Ubuntu until 2019. I ran it for about six months. Then I left.

The reason I told myself at the time was that Ubuntu felt slow on my hardware. I had an i3 first-gen Intel machine. Ubuntu felt sluggish in ways that bothered me. I blamed Ubuntu.

Here's what I discovered later: the culprit wasn't Ubuntu. It was GNOME.

GNOME is a beautiful desktop. I'll give it that. But on modest hardware, it feels less responsive, and even at times, it completely freezes. It shows up in the half-second delays, the slightly-too-late window redraws, and the sense that the machine is working harder than it should be.

XFCE saved my Linux life

The thing that actually kept me on Linux, the desktop environment I kept coming back to, is XFCE.

XFCE doesn't win "most beautiful desktop" polls. But I ran it on that i3 first-gen machine, and it ran smoothly out of the box. I ran it on a Core 2 Duo at some point.

Internet browsing, YouTube, writing articles, Django, and Python development, all of it, without considerable delay. XFCE in that sweet spot between functional and fast is something I haven't found matched elsewhere for low-resource machines.

I did try KDE. More than once, actually, I wanted to like it. I kept going back, hoping something had changed. What I found, every single time, was that a single click could take three to four seconds to get a response. It felt like the desktop was thinking about whether it wanted to comply with my input.

Even recently, a few weeks ago, I tried both CachyOS and EndeavourOS as live USB sessions in a VM, and both now default to KDE. I still felt it. That sluggishness hasn't gone away for me, and I've stopped trying to convince myself otherwise. XFCE remains my benchmark for a desktop that gets out of your way.

My Kali Linux Journey

After six months on Ubuntu, I switched to Kali Linux. And not for the reason you might think.

I had not suddenly become a penetration tester. I didn't have a burning interest in cybersecurity. I switched because Kali ran better on my hardware than Ubuntu did and because I was already comfortable with APT commands from my Mint and Ubuntu days, so the transition cost was essentially zero. I had access to the same package manager, familiar commands, and a lighter desktop.

I chose a distribution built for security professionals over the supposed beginner-friendly option. I chose not because of anything Kali offered that I needed, but because Ubuntu had made itself too heavy for the machine I owned.

The Arch Linux rabbit hole

By mid-2021, I'd been reading about Arch Linux mainly through all the BTW memes. The idea of an "expert's distro" appealed to me.

So I stayed up one night and tried to install plain Arch. I did not finish the installation.

What struck me was running commands to create partition tables and configure Wi-Fi. It was baffling. Not "this is hard, but I'll figure it out." More like: why has someone decided that an operating system installer should work like this?

I tried Fedora after. Then I tried Debian. In both cases, on my ageing hardware, boot times were bad enough that I found myself questioning whether the whole exercise was worth it. With Debian, I faced an internet connectivity issue as well.

The thing that drew me to Arch was Pacman and leanness. I kept asking myself: why can't the installation be as simple as Ubuntu's, but give me the system I actually want?

That's when I found EndeavourOS. It required no manual commands to connect to Wi-Fi. No writing partition tables by hand. Just select a disk, set your timezone, keyboard layout, and hostname, and you're done.

And when I booted in for the first time, I found the default looks fascinating. The default terminal: black background, blue accents, immediately distinctive. The default wallpaper was something I actually liked enough not to replace it, which almost never happens.

I used EndeavourOS for four-five years, I think.

What those "Arch" years looked like

I want to be honest about this stretch, because people who recommend Arch-based systems sometimes skip over the rough parts.

I hit the initramfs wall three or four times. That's the experience of booting your machine and being dropped into a minimal emergency shell with no desktop, no obvious path forward, just a blinking cursor.

The first time it happened, I didn't know recovery was possible. I reinstalled the entire system. Only later did I learn to boot from a live EndeavourOS USB, use arch-chroot to get inside the broken system, and rebuild the kernel from there. The culprit was usually a problematic package upgrade.

I also ran into keyring mismatches more than once, that particular class of Arch-ecosystem errors where package signatures don't line up, and installations fail with cryptic messages. The fix I settled on:

sudo pacman -Syu archlinux-keyring endeavouros-keyring

I'm sharing them because this is the actual texture of running an Arch-based system. It's manageable. I managed it. But a beginner who hits the initramfs wall on their third week of Linux use is probably not going to calmly research arch-chroot. They're going to conclude that Linux is unstable, and they were right not to trust it.

AntiX chapter and the limits of anti-systemd

Around mid-2024, I discovered AntiX Linux and ran it alongside EndeavourOS for roughly two years. It taught me a lot about IceWM as a window manager. For someone with a potato-tier hardware, old machines that most distributions have quietly given up on, AntiX is remarkable.

But I hit the systemd wall eventually. AntiX deliberately avoids systemd, which is philosophically interesting but practically limiting. A growing range of applications that assume systemd exists simply don't work cleanly. And I'll be honest: the AntiX GUI is not appealing. It's functional, and it works. But there's a visual coarseness to it.

After two years, I started thinking about moving on.

Returning to Kali for real this time

When you ask God which distro you should use

Now I'm back on Kali, but the circumstances are completely different. I really have an interest in cybersecurity, particularly bug bounty work. I'm running a Dell laptop with an i5 8th gen and 12GB of RAM now.

Two months in, I've had one issue worth documenting. Kali ships Firefox ESR, and if you want to remove it, the system objects, because Firefox ESR is part of the kali-xfce4 metapackage, and removing it wants to take other things with it.

The workaround I found: install the equivs package, use it to create a dummy Debian package with the same name as the dependency you want to satisfy, install that dummy, and the system believes the dependency is met. It's inelegant, but functional.

Where I am now: leaving XFCE for window managers

A lot is happening in the Linux desktop world around Wayland, Hyprland, and tiling window managers. The thing that excites me about this space, and I've come to believe this more firmly the longer I've used Linux, is the plain-text configuration model.

Your entire environment lives in text files you can read, version-control, back up, and restore. That's a kind of ownership over your system that no GUI settings panel can replicate.

I spent this past couple of months trying several options: Niri, Sway, and Scroll WM. I eventually settled on Mango WM as my main environment. I know, calling it a desktop environment feels technically wrong, but it's what I live in. The configuration philosophy suits how I think about my system.

That means I'm saying goodbye to XFCE after years of loyalty. Not because XFCE failed me, but because I've moved somewhere new.

Desktop environment, not distro

Looking back at all of it, I did not like Mint just because it's Mint. I felt comfortable with Cinnamon. I did not dislike Ubuntu because it's Ubuntu. It's because GNOME demanded more of my old hardware than the hardware could give.

Every distro-hop I've listed here, from Kali to Arch to AntiX to Mango WM, was really a hop between desktop environments and window managers wearing a different distro's name. The package manager changed. The installation experience changed.

What actually decided whether I stayed or left was always what sat on top: how fast it responded, how much RAM it wanted, whether I could read its configuration in a text file, how it felt to use.

The desktop environment mattered more than the distro.

If you're picking your first Linux setup, this is the question worth asking before you pick a distro: what desktop environment does it ship, and does that match your hardware and your preference?

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

This New Open Source Project Wants to Be the AI-First Alternative to Microsoft Office

Office suites have changed a lot since the first ones landed on desktops decades ago. What began as basic tools for typing letters and totaling numbers has turned into sprawling software loaded with templates, cloud sync, and now, AI.

It's 2026, and that last part has split the office suite market into two camps.

Microsoft has leaned into pushing AI everywhere, with Copilot showing up across Word, Excel, and PowerPoint whether you want it there or not. Others have gone the calmer route, building AI in as something you can turn on, not something forced.

GenOffice is a new offering from MainFunc.ai that strongly focuses on AI, putting it in the first camp, featuring a range of editors that one might expect from a modern office suite.

GenOffice: A quick look

Built by a single developer equipped with $10,000 worth of tokens (for AI), GenOffice bundles four editors, Docs, Sheets, Slides, and PDF, into one Electron-based desktop app.

For .docx work, Docs lets you draft a section, restyle a paragraph, or rewrite it for a different reader from a simple prompt, with the AI working directly inside the document rather than a side panel.

Sheets, for .xlsx files, runs on Univer, an open source spreadsheet engine, paired with an in-house Rust sidecar for reading and writing files.

Presentations run through Slides, which builds .pptx decks from a single prompt, picking a layout, writing the copy, and dropping in data cards as needed.

Rounding out the office suite is PDF, built on the open source pdf.js and pdf-lib libraries, letting you read long documents and ask questions about specific passages without you needing to switch between apps.

It's quite obvious that AI runs through every one of these editors. All of that is made possible via Genspark's Super Agent, which is treated as a core part of the app rather than a chat window tacked on the side.

Opening, editing, and saving files costs nothing, but AI features draw from Genspark's credit system, tying them to an account rather than a local model.

That matters, because GenOffice doesn't appear to have its own privacy policy. AI features run through Genspark's service, so anything you send them falls under Genspark's terms and privacy policy instead.

That policy states text fed to the AI features gets passed to third-party providers, including OpenAI, Anthropic, Google, xAI, and ElevenLabs, and that no API key is stored on your device.

Currently, GenOffice is available only for Windows (x64) and macOS on Apple Silicon. Intel Macs are not supported, and as you've probably guessed, neither is Linux.

Where's the Linux build?

I did find an open issue (very likely AI-generated) that mentions a native Linux build, filed by a community member. It explains how shipping GenOffice for Linux isn't as simple as it sounds.

As of writing, there was no reply from the lead developer of GenOffice, so I wouldn't hold my breath for a Linux build anytime soon.

If you still want to try GenOffice, you can grab installers for Windows and macOS from the official website or go through the source code on GitHub to see if you can get a Linux build running yourself.

---

Suggested Read 📖: 6 Best Open Source Alternatives to Microsoft Office for Linux

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

While Torvalds Makes Peace With AI in Linux, Greg Kroah-Hartman Draws a Line (Sort of)

Greg Kroah-Hartman's "clanker" branch started as his own experiment, where an AI-assisted fuzzing tool turned up real bugs in the ksmbd and SMB code. These days, he isn't the only one using it, as other contributors have started sending in patches of their own, tagged the same way.

So when he posted a new AI policy a few days ago, restricting use of AI, it wasn't him turning against a tool he's comfortable with. It was a restriction that applied to one part of the kernel, the one place he doesn't want AI anywhere near the code.

A new rule

In a post to the linux-staging mailing list, GKH said he's now proactively rejecting LLM-generated patches for drivers/staging, pointing to an "onslaught" of them showing up lately.

His reasoning comes down to what staging is actually for. The subsystem exists primarily as a training ground, full of relatively simple cleanups and API changes that let newcomers learn the submission process.

The project already skips "fix all the coding style issues" patches generated by automated tools because clearing out that mess would eliminate the reason staging exists. GKH argues an LLM doing the same cleanup work defeats its purpose while calling out wannabe tricksters by saying that:

And yes, it is VERY obvious when people submit LLM-generated patches, so don't think that just not disclosing the use of them will allow you to "get away" with anything here. The goal is for people to be able to learn, not to try to "trick" a maintainer. If anyone is determined to have deliberately "tricked" us, well, consider this your warning ahead of time...

There's an exception, a strict one that too. A genuine security fix found by an LLM can still be submitted, but only if the submitter has tested it on the actual hardware the driver targets and can convincingly explain how testing was carried out.

A line drawn while Linus makes peace

This move lands right as Linus Torvalds is coming around on AI. He's spent years shifting his stance, and in a recent mailing list post he made it clear to critics that Linux "is not one of those anti-AI projects," telling them to fork the project or walk away if they disagreed.

GKH's approach to drivers/staging fits inside the AI Coding Assistants policy, where he isn't undoing what Linus signed off on but rather focusing on a narrower scope.

He is treating this subsystem as a gym, one where developers are supposed to show up and lift the weights themselves, not have an AI do the reps and hand them the result.

That's the line GKH has drawn. AI can be used to carry out work elsewhere in the kernel, but in a subsystem built for people still learning, he'd rather they build it the hard way first.

💬 What do you think of GKH's decision? Will it help newcomers?

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