I second that about Nvidia GPUs. While Linux hardware support is really good, there is plenty of common, mainstream hardware that never was and never will be supported by Linux, usually due to uncooperative manufacturers. For Nvidia, their non-free driver is terrible and the nouveau driver in Linux is hit-or-miss. (Note, many people use either of those successfully, but the likelihood of success drops rapidly with any of: multiple displays, the need to dynamically change outputs, multi-GPU Optimus hardware or even laptops in general, and fully functional hardware acceleration.)

In my experience, printers in general are terrible, but HP LasetJet Enterprise m series printers are excellent.

[Can] a patch can kind of be like a hook?

In the free software world, a patch usually describes a file that lists lines to be added to or removed from another file (or multiple files). The most common use for this is probably with actual source code.

Binary (non-text) patches are also possible, and in Windows a software bug-fix “patch” would likely be mostly binary. In the free software world, it’s uncommon to use binary patches for updates; instead the source is patched (either in the main upstream project or by a distribution) and a new binary package is built and published.

Where you create a config file that has symlinks to all the executables like you mentioned?

I don’t really understand how those two questions relate, so I may not be able to give you a good answer. Often a configuration file has a variable=value structure, but it would certainly possible to have a list of file paths in a configuration. However, this might instead be implemented as an actual directory (like ~/.config/app/pre-hook.d/) where each executable file in that directory is executed by the “pre” hook in the app. (Configuration directories often work very similarly also.)

Whether the paths are symlinks is likely to be irrelevant, as this is more a filesystem level feature that would often be ignored entirely by the application.

I hope this is helpful.

A hook is a mechanism for adding functionality at a certain point in a program’s normal flow. As a simple example, imagine a program that works by doing three things in order. It could have hooks that allow the user to add actions before or after any individual steps. Each possible point in the flow is a separate hook. One way to implement it is with a directory for each hook in the program’s configuration directory, where executables can be placed; the hook runs each executable in sorted order.

I didn’t look up any of this, so it may not be the best explanation, but I hope it is helpful.

From the README at the current published commit:

The current focus is on implementing next-word suggestions, which has become complicated/hit a snag and is taking more time than originally planned. Updates will come when this issue is resolved. Thank you for being patient.

Prior to this, releases occurred quite regularly.

@whatever and @Flyswat, you’re right, it still happens with Jerboa 0.0.42. I didn’t realize the behavior was related to the specific keyboard in use.

Thanks for posting the GitHub link.

Yes, and it is very annoying. However it does not seem to be happening now with Jerboa 0.0.42.

Edit: This is still happening for me too, as of Jerboa 0.0.42, with the AOSP keyboard. It does not happen in any other apps.

It’s ironic but unsurprising, and my experience too, that some functionality works better with Nouveau than with the proprietary Nvidia drivers.

If you haven’t already, check for Nouveau support. And if your card is supported, you may need a kernel parameter. I needed nouveau.config=NvClkMode=15 (but be warned some parameters like that have some risk, like possibility of overheating, and may or may not be applicable or safe for your GPU).

For me, it has worked to just set environment variable DRI_PRIME=1 to use the Nvidia GPU for that specific application. (Maybe this is what Bumblebee does; I don’t know.)

In the future, though, I recommend avoiding Nvidia hardware.

As I mentioned in another comment, in my experience Nouveau does a much better job with multi-display and multi-GPU systems than Nvidia’s proprietary drivers. Unfortunately Nouveau’s actual hardware support is somewhat limited, so that is only relevant for a subset of Nvidia GPUs.

I, too, don’t want any more Nvidia hardware.

In my experience they just work once you install proprietary drivers

That’s not my experience with dual-GPU (Intel+Nvidia) hardware and multiple displays, where the standard xrandr functions are often used to modify the output configuration.

In my case, the Nvidia GPU is supported by Nouveau, so I can compare it with Nvidia’s proprietary drivers “side-by-side”. With Nouveau, display output configuration and per-application GPU selection both “just work” (I did add a nouveau.config kernel parameter to enable acceleration). I’ve never been able to make the proprietary drivers do those things reliably.

So I suggest that users with simple single-display, single-GPU systems are likely to have a better experience with the proprietary drivers.

As is the general consensus here, I do not plan to purchase any Nvidia GPU hardware in the future, especially considering that more recent Nvidia GPUs now require signed firmware, making Nouveau support impossible.

restic does do deduplication.

https://restic.readthedocs.io/en/latest/100_references.html?highlight=deduplication#backups-and-deduplication

Look at non-multi-function “Enterprise” laser printers. They are completely different than the consumer grade garbage.

I recommend an HP LaserJet Enterprise Mxxx printer, color or not, that is listed on the HPLIP All Supported Printer Models page.

You can find lightly used, older model ones on Ebay, sometimes even with a full toner cartridge(s), for much less than new price.

HP is still releasing firmware updates even for many older models, and the firmware is loaded with features (for example, if it is connected to your network, network printing works from Android and Apple phones without requiring any special apps). The firmware does not depend on any remote service.

If you even need them, the Linux drivers are free and open source and packaged in Debian main (for example); your don’t have to install some weird closed source garbage that won’t work in a few years.

People here are recommending Brother, but I don’t think they have free and open source drivers (think “nouveau vs. Nvidia”). Am I incorrect about that? In my experience, this can become a significant problem as software moves forward but the company does not continue to support their Linux binary driver.