Linux

cross-posted from: https://discuss.tchncs.de/post/15147078

This release adds the following features:

• Drop heap as part of a housekeeping action
• Retry downloads to workaround flaky network connections

This release fixes the following bugs:

• Assume new ME versions are called CSME
• Fix a buffer-overread when parsing invalid CoSWID entity data
• Fix a logic thinko when parsing GUID strings
• Fix downloading files on Windows with libcurl >= 7.77.0
• Revert back to a simpler syscall blocklist-based filter

This release adds support for the following hardware:

• Acer U32 dock
• Luxshare 7-in-1 dock
• Pixart models 2404, 4206, 2440, 2418, 2752, 2840 and 2818

Why the second identical disk is more expensive is beyond me (tried with 1TB Samsung 970 EVO Plus NVMe PCIs).

Rook is a lightweight, stand-alone, headless secret service tool backed by a Keepass v2 database. It provides client and server modes in a single executable, built from a reasonably small (auditable) code base with a small and shallow dependency tree - it should not be challenging to verify that it is not doing anything sketchy with your secrets.

Reasonable auditability, the desire to use KeePass files, and to do so through a headless tool that doesn't spawn off the better part of a DE through otherwise unused services, were the main motivations for Rook.

You might be interested in Rook if one or more of these are true:

• you use KeePass v2-compatible tools to store secrets already
• you are not running a DE like KDE or Gnome (although Rook may still be interesting because of secret consolidation)
• you prefer to minimize background GUI applications (KeePassXC is excellent and provides a secret service, but doesn't run headless)
• you run background applications such as vdirsyncer, mbsync (isync), offlineimap, or restic, or applications such as aerc that can be configured to fetch credentials from a secret service rather than hard-coded in a config file.

Pre-built binaries for limited OS/archs are built by the CI, and Rook if available in AUR. There's an nfpm config in the repos that will build RPMs and Debs, among others. I consider Rook to be essentially free of any major bugs and fit-for-purpose, although I welcome hearing otherwise.

Utility scripts in zsh and bash are available for providing autotyping and entry/attribute selection using xdotool, rofi, xprop, and so on; these are YMMV-quality.

Changes from v0.1.1 are:

Added

• one-time pin soft locking
• installation instructions for distributions that have rook in a repository
• more of the special autotype {} commands are supported (backspace, space, esc)

Changed

• getAttr adds a little delay before typing, allowing initiator tools (like rofi) to close windows before text is output
• cleans up code per golint/gochk

Fixed

• an autotype bug in outputting literals

We test the Linux-first, all-AMD Sirius 16 laptop, discuss the new Hyprland release, and share a few stories from our recent trip.

About 50% of the time, if I choose sleep, it turns back on as soon as it shuts down. This can happen a couple times in a row. Other times, it sleeps normally and only comes back on with keyboard input. I’ve looked at running processes and there doesn’t seem to be anything I dual happening at the times it starts back up. Any ideas?

Hi all,

I'm visiting a relative that has a Google WiFi system with multiple access points. There's an access point literally right next to me that I can see in the KDE BSSID list with 100% connection strength.

For some reason, it's instead picking a BSSID with only 60% strength. Does anyone have any thoughts on why it's choosing this access point instead of one of the others? Is this something the Google WiFi controls/suggests to the laptop, is something bugged, or is there a good reason Linux might be choosing this particular access point?

EDIT: It turns out the access point placement was actually just really bad, and the access point in question was not even making it to the rest of the LAN... The speed difference between my phone and laptop seems to be just that, something to do with a difference between the framework and the Pixel's wireless cards (or drivers). Even with everything corrected, the Pixel is significantly out performing the framework.

Does anybody know how that's going? It's been 2 years.

cross-posted from: https://programming.dev/post/9907720

The SSH port is 22. This is the story of how it got that port number. And practical configuration instructions.

I just noticed, that my SSD is almost full and I think it is because of all the zypper packages I got installed. I've got another ~100gb SSD thats just for stuff (mounted unter "Misc" says it all) and would like to move some (or all?) of the packages like vscode, podman or other stuff on that second SSD. Is there a way to do that with zypper without removing and installing them again under the new path?