Thanks for clarifying, and I can appreciate your overall concerns as I face the same dilemma with my aging relatives.
Just to confirm, have you opened these files in Word yourself (or witnessed them being opened), to verify they are in fact valid documents? if valid, are they meant to be in English?
It wouldn’t be the first time I’ve seen “other” files renamed with an incorrect file extension.
Assuming you meant “.docx files”, those should open without issue in LibreOffice. As others have said, OnlyOffice is another popular option if format preservation is a goal.
What do you mean when you say the files are “not supported” by the tools you’ve tried? What, exactly, is happening and what are you trying to accomplish? The end goal wasn’t clear to me from your post.
Getting Word to run under wine will require much more effort than copying the Word binary.
I don’t use RCS myself, but there are recent posts on the GOS forums and it appears to be working fine once all of the prerequisites are installed.
Sure, like I said above, GOS doesn’t at all prevent you from rooting the device. They only discourage it from a security point of view. Regarding MicroG, I’ve never had need for it myself but I’ve read many other posts over the years from users who have installed it on GOS in lieu of Graphene’s own implementation.
I would argue that overall GrapheneOS provides more control over the OS than some other Android-based operating systems.
You can root GOS like any other Android-based OS. It’s just highly discouraged, completely unsupported and, in the opinion of the GOS devs, you will no longer be considered to be running GOS since you are compromising the core OS by doing so.
You’ll need to provide specifics if you want solutions to many of these issues.
For the keyboard, there are several FOSS keyboards which support spacebar navigation, but you can also install Gboard and simply disallow any permissions, including network access.
Regarding Signal, this would be a reality for anyone with a non-Apple device. You may need to find a compromise and simply use SMS, RCS, or even just email when dealing with certain people.
There will always be one-off features available only on other devices or platforms. Only you can decide whether they are worth the cost of security and privacy.
If you’re now getting I/O errors that won’t even get you booted, it sounds to me like drive failure is imminent.
For what it’s worth, I’ve never had to change my io scheduler in the nearly twenty years I’ve used Linux. You can check your current scheduler with the following command: cat /sys/block/sda/queue/scheduler (change the block device to whatever yours is…sda, nvme0n1, etc.).
In my case, it was already bfq: one mq-deadline kyber [bfq]
Distrobox will resolve your issue with VSCode and then some. Run archlinux, debian or whatever you want as a container. Then, install VSCode/VSCodium (and any other apps that Chimera lacks) inside the container OS. This will keep your development environment containerized and safely away from your host OS.
Thank you, sebastinas and gang!
It definitely sounds like a hardware issue since it has survived multiple disk wipes and distro changes.
I’ve been very happy with both Silverblue and Kinoite. I’ve installed it to all of my workstations now and can’t imagine ever going back to a traditional distro.
Your comments suggest that you’re already aware of distros like Silverblue so, if I may ask, how are these different than what you’re looking for? Silverblue comes with several flatpaks installed, but you can easily remove these and you’ll be left with a pretty barebones ostree image.
We swapped our 2080s for 6800 XTs last year and couldn’t be happier…a 7900 GRE should be great for gaming, but I can’t speak to LLM performance.
I was able to extract the img from the ISO using geteltorito as described in section 5 of this ArchWiki article. Once you mount the resulting img file, you’ll end up with the same file contents achieved by running their Windows BIOS Utility through wine.
The relevant binaries appear to be under the folders, N24ET76P and N24ET76W. Both scan clean for me, for whatever that’s worth:
curl -X POST -F'file=@N24ET76P/$0AN2400.FL1' https://pk.fail
{"details":{"analysis-time":"1.395106993s","hashes":{"md5":"ba73792a5fc831ca84b4cd3a21c03247","sha1":"24a5bb42d670c7705aed06588f0092ec11a32564","sha256":"b9510c73657460ae24c550b71d217a543b0fc3c30a3e081eff31d9d8f1a2bdda","sha512":"8ef6f0dcffbca05b79710b8599b1b1c926ee59185a675bc7eeede6da040c751097303ada523611271de6aaf190a597cdd6e9d5cf564d06987abcf712f61227c6"}},"status":"not-vulnerable"}
curl -X POST -F'file=@N24ET76W/$0AN2400.FL1' https://pk.fail
{"details":{"analysis-time":"1.438471526s","hashes":{"md5":"de1551b0bcc73e19375f7111def72278","sha1":"cd41f36d018f940c308a7be25a20e81bdb7e4cf2","sha256":"b3f646095e47bb94f04390c756cb4133201b1231a8b224174f10bb06bd3835f2","sha512":"55143f4903f92d88057bc9d4232b0d328e9ace36330f35fafdf0485d8bebb3f79b9fedc88ab1dec7fc04a8a3e0890887c1dd7632a2ffa397fb0917be90e3f93f"}},"status":"not-vulnerable"}
The linux command mentioned in the Ars Technica article elsewhere here is efi-readvar -v PK. For Fedora and Arch users, efi-readvar is available in the efitools package.
Edit: Clarity
deleted by creator
An ISO is just another archive format, similar to zip, tarballs, and rar files. Most modern archive tools can open and/or extract its contents like any other archive.
Edit:
It looks like Lenovo releases their ISOs formatted as a CD image. See: https://workaround.org/article/updating-the-bios-on-lenovo-laptops-from-linux-using-a-usb-flash-stick/
I can’t say for certain, but I think you just have to grab the last firmware binary released for your T480 from the Lenovo website and run it through the online validator: https://pk.fail/
You should be able to layer the xdg-desktop-portal-gnome package, which will also pull any dependencies.
To answer your general question though, yes I believe you can easily install at least minimal versions of each DE with little impact to rpm-ostree performance. They don’t need to be separate images, though that’s possible too by rebasing and pinning. I would just layer the necessary packages to load a GNOME environment (start with rpm-ostree install gnome-shell). This way everything stays up to date with the active image. For example, I’m running GDM under Kinoite simply because I was having unresolvable issues with SDDM and LightDM.
Pinning separate images would require you to rebase with each image update and then unpin/pin the old/new images…too much work.
Not mutually exclusive, but it’s highly probable that if you’re running a mainstream distro, the default kernel is in lockdown mode, preventing hibernation while secure boot is enabled.