It’s faster and more memory efficient basically. skim also appears to have been abandoned (no updates in over an year), whereas two_percent is being actively developed.

Those of you reading this might also be interested in two_percent, which is a fork of skim, which in turn is a Rust implementation of fzf. two_percent is faster, more efficient and uses less memory than fzf, which is especially noticeable with large inputs.

No need to hop around for the same thing.

It’s not really the same thing. EndeavourOS is basically vanilla Arch + a few branding packages. CachyOS is an opionated Arch with optimised packages.

You still have the option to select the DE and the packages you want to install - just like EndeavourOS - but what sets Cachy apart is the optimisations. For starters, they have multiple custom kernel options, with the BORE scheduler (and a few others), LTO options etc. Then they also have packages compiled for the x86-64-v3 and v4 architectures for better performance.

Of course, you could also just use Arch (or EndeavourOS) and install the x86-64-v3/v4 packages yourself from ALHP (or even the Cachy repos), and you can even manually install the Cachy kernel or a similar optimised one like Xanmod. But you don’t get the custom configs / opinionated stuff. Which you many actually not want as a veteran user. But if you’re a newbie, then having those opinionated configs isn’t such a bad idea, especially if you decide to just get a WM instead of a DE.

I’ve been thru all of the above scenarios, depending on the situation. My homelab is vanilla Arch but with packages from the Cachy repo. I’ve also got a pure Cachy install on my gaming desktop just because I was feeling lazy and just wanted an optimised install quickly. They also have a gaming meta package that installs Steam and all the necessary 32-bit libs and stuff, which is nice.

Then there’s Cachy Browser, which is a fork of LibreWolf with performance optimisations (kinda similar to Mercury browser, except Mercury isn’t MARCH optimised).

As for support, their Discord is pretty active, you can actually chat with the developers directly, and they’re pretty friendly (and this includes Piotr Gorski, the main dev, and firelzrd - the person behind the BORE scheduler). Chatting with them, I find the quality of technical discussions a LOT higher than the Arch Discord, which is very off-topic and spammy most of the time.

Also, I liked their response to Arch changes and incidents. When Arch made the recent mkinitcpio changes, their made a very thorough announcement with the exact steps you needed to take (which was far more detailed than the official Arch announcement). Also, when the xz backdoor happened, they updated their repos to fix it even before Arch did.

I’ve also interacted with the devs pesonally with various technical topics - such as CFLAG and MARCH optimisations, performance benchmarking etc, and it seems like they definitely know their stuff.

So I’ve full confidence in their technical ability, and I’m happy to recommend the distro for folks interested in performance tuning.

cc: @[email protected]

I have a Zen 2, Zen 3+ and a Zen 4 system and they all work well very with various Linux distros (Arch, Fedora) and recent kernels.

It’s very likely that your bug is specific to early Ryzen CPUs/chipsets. A couple of folks on those reports mentioned their issues went away after a motherboard/BIOS upgrade. So I think you’ll be fine if you went for a more recent AMD CPU+mobo.

And the ones who install Arch on a MacBook need extra special therapy.

Laughs in Fedora 39

This is old news. This article was published on 7 Aug 2023.

In one of my previous roles as a sysadmin, our company signed a deal with HP to directly supply enterprise laptops to one of our clients as part of Microsoft’s Autopilot deployment model, so users could get a new/replacement laptops directly and get it customized on the fly at first logon, instead of us having to manually build it the traditional way and ship it out. It worked fine in our pilot testing, so we decided to roll out to the wider audience.

However, one problem which arose after the wider rollout, was that SCCM wasn’t able to connect to any of these machines (we had it in co-management mode), and even the laptops which were able to communicate previously, stopped communicating. It was working fine in our pilot phase, but something was now blocking the traffic to SCCM and we couldn’t figure it out - it was all okay on the network/firewall side, so we thought it could be a configuration issue on the SCCM server side so we raised a priority ticket with MS. After some investigation, we found the root cause - turned out out to be this nasty app called HP Wolf Security - which was new at the time - which HP started tacking on to all devices, unbeknownst to us. Wolf was supposed to be an “endpoint protection” solution - which no one asked for, especially since we already had Defender. Searched online and found tons of similar issues reported by other users, all caused by Wolf. Lost some of my respect for HP since then - who tf pulls stunts like this on an enterprise level?!

The current one works fine for me, haven’t really had any issues. There is an updated fork on Github, but they haven’t made a release yet (and they haven’t changed/fixed anything major yet).

The main benefit is that it’s lightweight and doesn’t have some of the performance issues that Dark Reader has. Also, if has a bunch of different themes (so you can have more color schemes, similar to any modern text editor), finally you can also create your own theme for a particular site, if the built-in themes don’t look good.

What kind of “everyday” server stuff is efficiently making use of ≈300 cores? It’s clearly some set of tasks that can be done independently of one another, but do you know more specifically what kind of things people need this many cores on a server for?

Traditionally VMs would be the use case, but these days, at least in the Linux/cloud world, it’s mainly containers. Containers, and the whole ecosystem that is built around them (such as Kubernetes/OpenShift etc) simply eat up those cores, as they’re designed to scale horizontally and dynamically. See: https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale

Normally, you’d run a cluster of multiple servers to host such workloads, but imagine if all those resources were available on one physical hosts - it’d be a lot more effecient, since at the very least, you’d be avoiding all that network overhead and delays. Of course, you’d still have at least a two node cluster for HA, but the efficiency of a high-end node still rules.

Midnight Lizard, it’s better than Dark Reader. Skip Redirect is also pretty handy to fast-forward those pesky url shorter page redirections.

A GPU is used for a lot more than just gaming these days. It’s used to render videos, accelerate normal 2D programs (like some terminal emulators), accelerate some websites/webapps (those which use WebGL for eg); also modern DEs like Gnome and KDE also make use of it very heavily, for instance for animations and window transitions. Those smooth animations that you see when you activate the workspace switcher or window overview? That’s your GPU at work there. Are your animations jittery/laggy? That means your setup is less than ideal. Of course, you could ignore all that and just go for a simple DE like XFCE or Mate which is fully CPU-driven, but then the issue of video acceleration still remains (unless you don’t plan on watching HD videos).

Without the right drivers (typically NOT nouveau, unless you’re on a very old card), you may find your overall experience less than ideal. As you can see in their official feature matrix , only the NV40 series card fully supports video acceleration - these are cards which were launched between 2004-2006 - that’s practically ancient in computer terms and I highly doubt your PC uses one of those. Now recent-ish cards do support video acceleration, but you’ll need to extract the firmware blobs from the proprietary drivers (which can be a PITA on normal Debian as it’s a manual process), plus, even after that, the drivers won’t support some features that may be required by normal programs, as you can see from the matrix.

The natural solution of course would be to install the proprietary nVidia drivers, but you do NOT want to do that (unless you’re a desperate gamer) as there’s a high possibility of running into issues like not being about to use Wayland properly, or breaking your system when you update it - just Google “Linux update black screen nVidia” and you’ll see what I mean.

You’ll be avoiding a lot of headache if you just went with AMD; or even just onboard graphics like Intel iGPUs (if your CPU has it) would be a much better option - because in either case, you’ll be using fully capable and stable opensource drivers and you won’t face any issues with that.

Also, watch this video: https://youtube.com/watch?v=OF_5EKNX0Eg

deleted by creator

deleted by creator

We don’t, but from what I’ve seen in the past, those sort of forums either require registration or payment to access the data, and/or some special means to download it (eg: bittorrent link, often hidden behind a URL forwarders + captchas so that the uploader can earn some bucks). A simple web crawler wouldn’t be able to access such data.

private

If it’s on the public facing internet, it’s not private.

Autotype is already solved - ydotool, wtype and dotool exists (and possibly others as well).

Screen magnification is already present in KDE (Meta + +, Meta + - to zoom in/out). There’s also a magnifier tool (KMag). There may be similar functionalities in other DEs.

My issue is the lack of an overall GUI automation tool, ie, like AutoHotkey. X11 had PyAutoGUI, but there’s no such AIO equivalent for Wayland yet, and the PyAutoGUI devs don’t seem to be interested in Wayland support - it’s neither on their road map, nor have they even answered any Wayland questions on their Github page, which is disappointing. But this isn’t Wayland’s fault, when other tools have shown that automating the GUI is possible, we just need someone to put together a complete package like PyAutoGUI / AHK.

That looks promising. Thanks!

So how do you do it? Like, what’s the Wayland equivalent of xinit ssh -X user@remote-server startkde to forward an entire desktop session?