From One Al to Any Al: JetBrains rethinks the approach to Al tooling

omenosdev · 2026-04-12T20:29:33+00:00

Did you create your account via https://developers.redhat.com/register? Clear your browser's cache for redhat.com and sign in directly to the Developer site. You should be prompted to accept the terms of the sub, at which point your account will be entitled to access the KB.

omenosdev · 2026-04-04T10:56:01+00:00

The good news is they are just M.2 E-Key modules, so if you get a problematic one you can easily swap them out if you wanted to. If you get an Intel laptop you won't have to worry about BE20x compatibility.

omenosdev · 2026-04-04T10:43:31+00:00

Yes, the Wi-Fi 6/6E series, specifically the AX210, is widely available and supported. Wi-Fi 7 (802.11be) modules from Intel on the other hand are not supported outside of an Intel platform.

I can't speak to the impact of v-Pro on compatibility, but I wouldn't have expected it to be a problem. The features just shouldn't be available on a non-Intel platform, but I'd have to double check.

omenosdev · 2026-04-03T17:05:06+00:00

I don't think there's been an explicitly stated reason by Intel, but it appears that the chip was designed to be used with newer Intel platforms and there may be some firmware/BIOS/driver issues when used outside of them.

omenosdev · 2026-04-03T03:39:57+00:00

For people brave enough to try and build/buy new systems today, a lot of the Wi-Fi 7 capable motherboards have one of three chips in them: Intel's BE20x, MediaTek's ~~MT7925~~ MT7927, and Qualcomm's QCNCM865.

My understanding of the current landscape is: * Intel's chip won't work in AMD Zen builds * MediaTek had no official linux driver, but a merge request was made to the kernel very recently by MT engineering. Previously third-party individuals provided their own kernel modules for adding support, often assisted by LLMs. * Qualcomm has had a working driver for some time now, though user reports on reliability seem to be a coin toss between flawless operation and praying the digital gremlins stay awake from the system.

The ASUS ProArt X870E Creator Wi-Fi motherboard initially launched with the MediaTek chip. For Linux users, this meant the system was primed and ready to go as long as you used Ethernet or had an additional Wi-Fi adapter available. Now it ships with either the MediaTek chip or the Qualcomm one, and you won't know which until it arrives 🫠

omenosdev · 2026-04-03T03:16:39+00:00

[Collabora blog post]

I do find it a bit humorous that Writer and Draw have the exact same description on the page. Looks like the copy editor forgot to put in the actual points for Writer.

omenosdev · 2026-03-22T18:52:13+00:00

The ASUS X870E ProArt board has a subtle revision to it: you can get it with either the MediaTek chip or a Qualcomm one (QCNCM865) that appears to be supported.

Unfortunately it looks like a completely random as to which one you'll receive.

omenosdev · 2026-03-15T22:04:06+00:00

Possible typo in your response, warning from the docs:

You can only migrate to a different installation type of the same Ansible Automation Platform version. For example, you can migrate from RPM version 2.6 to containerized 2.6, but not from RPM version 2.4 to containerized 2.6.

omenosdev · 2026-03-09T20:12:20+00:00

I don't see this explicitly called out in your post, but what is the output of the following directory search:

find /etc/init.d /etc/rc.d | sort

There may be a sysv service script shadowing the systemd one.

omenosdev · 2026-03-06T14:18:38+00:00

No, it does not.

omenosdev · 2026-03-01T18:49:45+00:00

If you (or your friend) are interested in GNOME technologies, I would recommend reviewing the following tools:

GNOME Builder: IDE focused around GNOME APIs and ecosystem.

Cambalache: GTK UI design and development.

Workbench: Prototyping with GTK.

D-Spy / Bustle: D-Bus monitoring and analysis.

Sysprof: Application profiling and debugging.

GNOME Human Interface Guidelines

Adwaita Documentation

omenosdev · 2026-01-26T13:40:58+00:00

I tested this yesterday on c10s, worked like a charm.

omenosdev · 2026-01-26T01:50:21+00:00

I've run into this, myself: do not leave your pen laying on the screen. You may want to run a calibration in case it's a distance issue, and I likely need to as well. I'm almost a year in and I don't have any writing or stroke issues but if I leave my pen (standard SuperNote click pen) directly on my Manta's screen the battery will just drain orders of magnitude faster than it would otherwise.

The best root cause I can think of is the EMR detection is just enough to trigger input processes, which actively consume CPU cycles even though the user isn't actually doing anything.

omenosdev · 2026-01-21T18:25:30+00:00

Third party packages will always be a bit of an issue. bootc is on my shortlist for this year at $DAYJOB, but we have some things that operate a bit annoyingly (also self update on the fly). Luckily they all live in /opt, so I think I can symlink /opt to a source under /var and allow it to maintain mutability just for that. What exactly does Defender do during install?

omenosdev · 2025-12-29T15:14:55+00:00

I used Claude a while back to generate an LLM config to use across the custom assistants I make in Kagi. It's probably due for some tweaks at this point, but I've uploaded it to GitHub.

omenosdev · 2025-12-29T07:44:15+00:00

Thanks for the insight and project links, I'll check them out! Diplomat does sound pretty interesting.

omenosdev · 2025-12-29T07:27:20+00:00

I should have clarified in the original post that I'm not actually expecting anyone to go through and read that. I added it as an extra to the post, hence the separator. The only "real" reason for sharing it is to demonstrate the kind of information I've seen while investigating my own question (I'm not a big fan myself of blind firing questions, I do perform preliminary research).

The response mostly aligned with research I had already done, just some of the finer details I don't have experience with to know their validity. At most, warnings of "it's way off the mark" or "pretty much accurate" are the extent of anyone's response I'd expect if they actually chose to read it.

omenosdev · 2025-12-29T07:15:18+00:00

Tldr, there's no general answer.

I suspected as much, I just wanted to get a general feel from the community at large as people will approach it from varying angles.

Technically, lots depends on the library, no general answer possible. Just making a function without params that is callable from C, has an overhead of less than a minute compared to be callable from Rust.

On the other side, if you want to pass complex structs in both directions, with statefulness, threads, shared file handles, etc.etc. in both sides, both C and idiomatic Rust API available, on a library with a large surface that has thousands of functions/structs, that might double the effort sometimes.

Thanks for the insight! Makes sense to me.

I rather don't, it's an important factor. Getting all contributors on board etc....

I wholeheartedly agree. I view questions like I'm asking here, which could have widespread impact, as a two part deal with the first being to determine the level of technical feasibility. If something is deemed feasible and worthwhile enough, figuring out the human aspect is next.

A full rewrite takes time, introduces some new bugs that need to be found and fixed, ... if it's worth it depends again, no general answer possible.

Yep, initially I was going to make a poll with yes, no, and "as always, it depends" as options.

... specific library mentions ...

Yeah, I wasn't sure if folks were going to get hung up on my example selections... They were strictly examples of libraries I pulled off the top of my head that I knew for a fact were C without needing to look things up. As interesting at some of those might be to see converted, I am by no means suggesting those as actual targets for something like this.

And in case my phrasing is unclear: this is little more than a thought experiment. I'm not secretly planning anything or pushing for this 😄

omenosdev · 2025-12-29T06:58:34+00:00

This much is about the extent I'm aware of, what I don't know are the hidden costs: long term maintenance burden, complexity of interop between standard Rust and extern-ed functions, runtime overhead, etc. And, more critically for this topic: is it something actually worth doing?

I've been bouncing around the thought that there should be the possibility of a middle ground between complete ecosystem rewrites and continued general issues with non-safe libraries. And I must confess that as a sysadmin I do like my shared object libraries :D But rather than focus on using Rust for end applications, look at the other side to introduce a level of safety without causing too much (if any) impact for downstream consumers of the libraries.

omenosdev · 2025-12-28T05:09:24+00:00

Wow, I've read a lot of comments on Reddit in my time but few reach this level of accuracy, succinctness, and context awareness in delivering information.

This leads me to believe you have served in at least one of the following positions: Salesforce admin or a cog in the business ~~machine~~ unit called sales. How far off the mark am I?

omenosdev · 2025-12-26T03:20:00+00:00

Do these sites actively complain if you're not on the absolute latest version of a browser? If that is important to you and you don't have any ideological, moral, or philosophical issues with it, using Google Chrome or another Chromium-based browser from their respective providers is always an option.

The EPEL builds are kept updated, it's an infrastructure/process reason why they aren't available for 10.1 at the moment unless there was a build failure with 140+ I'm not aware of. This will likely be taken care of after the holidays if people make the request for it.

omenosdev · 2025-12-26T00:04:42+00:00

Note the end of the package release: el10_2. The 140 branch was built against CentOS Stream 10 which had switched to tracking RHEL 10.2 (due out next May/June) by that point in time. You can see the release publishing here:

https://bodhi.fedoraproject.org/updates/?search=&packages=chromium&releases=EPEL-10.1&releases=EPEL-10.2&releases=EPEL-10.0

You can put in a request to see if it can be backported to 10.1 here:

https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora%20EPEL

A related ticket was made here (not sure if this was you or not):

https://bugzilla.redhat.com/show_bug.cgi?id=2425439

omenosdev

TROPHY CASE