That is correct.

However, this is a quasi-monopoly by google having quietly overwhelmed the space. Same thing for RCS messaging.

Neither push notifications nor RCS are proprietary, so there is a possibility to tear oneself from google here.

For instance, there are several free and paid push notifications services. Pushbullet is a popular paid one, not too expensive. I personally use https://ntfy.sh/, which can be self-hosted.

RCS is different because trusting the encryption keys makes RCS work, so there would have to be a critical mass of buy-in to use an alternative to google’s RCS implementation.

Oh, you are failing one over if the other fails? That’s not the same thing as configuring two interfaces with the same IP, gateway, at the same time, which is what I thought you were trying to do.

Is it possible to configure interfaces this way? Yes.

Will it work? No, not without bonding, and not with WiFi as one of the interfaces.

This has been the case since android 6. It just didn’t show you that message and would simply refuse to update non-play store apps.

Depends what version of the Surface, but I have a Surface Pro 6 and it still performs well. I use the Surface Linux kernel.

Those are considered firmware, yes. And these can vary in their installation as being updated via the firmware interface itself or some other update mechanism.

Some firmwares like on certain IBM thinkpads, my surface pro 6 and others can be updated directly via a Linux command called fwupd, but the firmwares must live in specifics public repositories.

This news means we’ll all have a much better time using fwupd to update these on dell and lenovo machines, but the firmwares themselves will remain proprietary blobs.

Coreboot replaces the bios/firmware altogether, and it’s not an easy task to get new ones, unfortunately.

This is talking about fwupdt firmware and patches, not uefi/bios replacement.

The trump comments aren’t the issue, it’s Proton’s acknowledgement that they will turn over data to the swiss police when asked.

BTRFS and ZFS both use block compression, ZFS by default. It’s meant to increase both storage efficiency and access speed and has nearly zero impact on performance. The files aren’t compressed from the filesystem point of view, which would satisfy your requirement not to need any other tools.

I’m confused about your statement that you don’t want to save space with compression, but you indicated that you want to “make the most of your storage”. Are you looking for long-term archiving?

It’s not clear here if you mean block compression, file compression, or stream compression.

It would be nice, but the time it takes to do the work of validating package versions for LTS candidacy is either limited or not free, so this is the acceptable compromise.

Are you waiting for a kernel patch, or is this support simply not available yet?

Use ps -ef to find the source of the file.

Security is nice to have but it’s not the reason I’m using Linux, so handing over my photo ID to a third party I trust is an acceptable if disappointing risk.

And for us who don’t find it an acceptable risk? Will I need an ID to read a book next?

Man, I’m trying to soften on AI, but this post is just awful.

I’m not gonna say “don’t do it”, but I’ve dug into this deeply and I’ve turned away from RISC V.

RISC V is slowly being pidgeon-holed into embedded systems. This is not a bad thing, the embedded market (cars, tvs, industrial controls) is huge and diverse.

RISC V has had a very rough start to introduction into bridge-and-bus systems the way we know from Intel/amd because there have simply been too many iterations of CPU registers and capability flags for integrators to take the platform seriously enough to commit to piling a bunch of effort to design, produce, and lead sales on any RISC V platform. Even arm (especially v9) has settled some of these platform issues and is ahead of RISC V in adoption in the integrated platform space (as opposed to embedded).

Long story long, it is extremely difficult to write device drivers for RISC V because one would have to write half a dozen architecture versions, just for a niche platform that barely sells. Conversely, an embedded controller for, say, a vehicle gets a preliminary build and few revisions, ongoing support isn’t part of planning the same way.

Debian and alpine. Coming up on 27 years of linux for me.

What is “cross process rendering”?

Meh… There have been a whole lot of braindead “pls do it for me” posts going around since the influx of windows refugees.

I’m not one to be a prick about answering questions to help out, and we all start somewhere, but “help me get steam and my LLM working on Kali linux” where ppl get in way over their heads is becoming a real problem. Worse, they will call the linux community toxic for suggesting they need more fundamentals first.

I interpret the post title as a general “try your best, and come to us when you’re stuck”.

Honestly, incus.

I know it’s not strictly a utility, but holy cow, Stephane Graber and his team have put the work into that product, such that anything you can do in the ui can be done in the CLI, and more.

Tab completion entries for all the resource types (storage, instances, image repos, etc), help entries for everything, it brings a tear to the eye.

I once thought it was cool to have standardised man entries, but even better is context-sensitive --help entries that work well. Almost all the discovery I’ve made using incus, I’ve made using the commands themselves.

It’s a real testament to how putting in the documentation work might be tedious, but it is a boon to both users and devs.