What are your requirements? I liked CalenGoo, I can live with aCalendar and BusinessCalendar.

I’ll post some links, but it’s a pretty busy week for me already, so give me some time.

An interrupt is an input that can be triggered to interrupt normal execution. It is used for e. g. hardware devices to signal the processor something has happened that requires timely processing, so that real-time behavior can be achieved (for variable definitions of real-time). Interrupts can also be triggered by software, and this explanation is a gross oversimplification, but that information is what is most likely relevant and interesting for your case at this point.

The commands you posted will sort the interrupts and output the one with the highest count (via head -1), thereby determining the interrupt that gets triggered the most. It will then disable that interrupt via the user-space interface to the ACPI interrupts.

One of the goals of ACPI is to provide a kind of general hardware abstraction without knowing the particular details about each and every hardware device. This is facilitated by offering (among other things), general purpose events - GPEs. One of these GPEs is being triggered a lot, and the processing of that interrupt is what causes your CPU spikes.

The changes you made will not persist after a reboot.

Since this is handled by kworker, you could try and investigate further via the workqueue tools: https://github.com/torvalds/linux/tree/master/tools/workqueue

In general, Linux will detect if excessive GPEs are generated (look for the term “GPE storm” in your kernel log) and stop handling the interrupts by switching to polling. If that happens, or if the interrupts are manually disabled, the system might not react to certain events in a timely manner. What that means for each particular case depends on what the interrupts are being responsible for - hard to tell without additional details.

I shudder to think OP’s post was written by an actual person…

People often believe they are hearing ultrasound, but instead are hearing clicking noise or sub-frequencies emitted from the capsule that are not actually part of the ultrasound.

Pixel 6 Pro worked marvelous for me all the time. I have the 8 Pro now, and now the fingerprint reader is a real mess.

But yeah, the reader on the back was perfect.

Yes, targeted attacks like that definitely exist, most famously maybe the most recent social pressure to merge a vulnerability to the xz library by actor “Jia Tan”:

https://arstechnica.com/security/2024/04/what-we-know-about-the-xz-utils-backdoor-that-almost-infected-the-world/

This started a whole discussion about relying on (often unpaid) volunteer work for critical systems and the pressure and negativity these people face, which is a discussion that was absolutely needed, and which we are still lightyears away from fixing.

Currently, open source is still treated like this: https://trac.ffmpeg.org/ticket/10341

(I can only recommend reading the whole story around this issue, which boils down to Microsoft admitting they rely on an open source project for something they consider critical to their customers, but not willing to pay the maintainer a bounty for fixing the issue)

That’s why there is a huge market for 0-day exploits.

I am on my 4th personal TUXEDO laptop, never had any issues. I actually started giving them to the devs at my company, no complaints so far.

They don’t offer my choice of OS, and I wouldn’t use a preinstalled OS anyway, so I can’t comment on that.

Couldn’t watch, so I got a summary. Maybe it’s helpful for someone else:

• Bluefin is introducing a new “Stable” tag for their Fedora distribution, in addition to the existing “GTS” (Grand Touring Support) and “Latest” tags.

• The Stable tag will provide a middle ground between the aggressively updated Latest Fedora and the more conservative GTS version.

• Stable will use the latest Fedora release, but with a slightly older kernel that has been more thoroughly tested and vetted by the Bluefin team.

• This is intended to cater to enthusiasts who want the latest Fedora features, but with a bit more stability and reliability.

• Bluefin will be publishing weekly updates for the Stable images, rather than waiting 2 weeks between updates like the Fedora CoreOS team.

• The Stable images will also use zstd chunked compression to reduce the amount of bandwidth needed for updates.

• Bluefin is unsure whether the Stable configuration (latest Fedora, slightly older kernel) or the GTS configuration (older Fedora, latest kernel) will ultimately feel more stable in practice

• The Stable tag is a response to user feedback requesting access to the latest Fedora releases, rather than having to wait for the GTS version.

• Nvidia driver updates for the Stable images will also be provided on a regular basis.

• Bluefin is interested in exploring this middle ground between aggressively updated and conservatively updated Fedora distributions.

Generally all correct, here is a resource with a lot of in-depth information and additional links:

https://batteryuniversity.com/article/bu-808-how-to-prolong-lithium-based-batteries

It’s not true that precision measurements are impossible with low value resistors, a lot of measurement equipment works exactly like that - it might just be more expensive than what the manufacturer is willing to budget for.

Tuxedo also offers products with an aluminum body, and while they do import the hardware from China, you get the local service and warranty guarantees any company in the EU must provide, so that’s fine by me.

Also, honest question: what do you think a unique laptop is, in particular when buying from a mass consumer brand like Lenovo? I really can’t figure out what that’s supposed to mean.

lspci will read the vendor and device id via PCI and use that to determine what the device is. You might want to make the output a bit more digestable / useful via lspci -s 03:00.0 -k -nn, but I’d assume the ids that match an 2070 will show up.

Could you please take the card out and provide us with a few pictures from different angles, maybe getting a good look at the actual chips?

I’d like to rule that out before chasing rabbits here.

Also, you could always run nvidia-settings, which will show information about an NVIDIA card using a different access method.

I’d still like to see the pictures of the card though ;)

Sure. But the number of targets you could acquire there is miniscule compared to simpler delivery mechanisms, via a malicious app download, for example, and you have larger costs (hardware) and added risks, e. g. being captured on CCTV during installation.

That’s why I said, the cost/reward ratio is really off.

Oh, that makes everything a lot easier. The majority of the relevant settings will be in your home folder then, i. e. in the ${HOME}./.config folder, while some might also be in ${HOME}/.local/share etc.

You probably want to backup the whole home folder anyway, so that would pickup most of your settings. In order to make that work on a different system, you would have to install all applications you were using on the tablet as well. Luckily, software installation in Linux is pretty easy, so you can export a list of installed applications from the Surface and then re-install them on your target system before migrating your home folder. The software list should become part of your backup. See e. g. https://unix.stackexchange.com/questions/82880/how-to-replicate-installed-package-selection-from-one-fedora-instance-to-another for an idea of how to perform this.

I have used this approach in the past and it will get you 95% there. There might be some global system settings that you’d like to also transfer to your new system, but you can add those as you discover you miss them on the target system.

In general, no, this won’t work. In your case, you’re lucky since at least the Surface Go is using an x86 CPU, so it’s not completely out of the question, but transferring the image as-is to a completely different device typically does not work without modification.

Simple example: your target device might not refer to existing hardware (let’s say a storage medium) in the same manner as your old device, so the existing references in your cloned image won’t work. There are other issues of course, e. g. missing drivers for different hardware present on the target device.

It’s possible to modify the image so it would boot, but given the Surface runs Windows, that’s going to be a chore. I’d consider this an interesting project if bored on a slow weekend, but I’d most likely just do a filesystem backup of relevant data and call it a day.

Honestly, that just seems like you’re treating dd as some kind of arcanum. dd works just fine and I’ve been doing 1:1, full system backups for decades with it, no issues. Honorary mention for ddrescue / dd_rescue for recovery options, i. e. re-trying bad sector reads etc.

In fact, when Clonezilla doesn’t know your filesystem, it will simply employ dd to copy the data sector by sector.

I’d argue that Clonezilla (due to its use of partclone) is actually a less complete form of backup, since it will only copy used blocks, you don’t really end up with a clone of your devices, just a copy of what partclone believes to be your data. Don’t get me wrong, that is fine in most use cases, but there are some cases where this doesn’t cut it, e. g. wanting to backup / restore a storage device from a PLC where the vendor had the glorious idea to store licensing data in unused sectors, or when you want to create a forensic disk image, might want it look into d3dd then, although it absolutely works using regular old dd as well, d3dd just adds some amenities.

All I want to say is: dd is an absolutely reliable tool and can be a one stop solution for device backups. Also, I have absolutely no quarrels with Clonezilla, if it fits what you’re trying to do and it works, great.

Not necessarily, if you find an exploit that allows you to install malware without user interaction, Mactans famously did that for an older iOS version.

I’d still argue that making good use of such an exploit and rolling out the necessary, physical infrastructure does not have a great cost/reward ratio.

The best way would in fact be testing it with an electronic load that applies a precise and well known load to the battery and integrates capacity until a matching shutoff condition is reached.

However, the majority of people do not happen to have access to such an instrument, so I’d say your suggestion is a close approximation of the best way, which could be augmented by adding simple measurements, which can be done by most people at home for a reasonable, quantifiable judgment.