There’s not really much of a point using the RCS Test app, as it’s only a demo of very basic RCS features.
The thing with RCS is that whilst the “official” spec (ie the Universal Profile), as defined by the GSM Alliance, is open, it doesn’t implement or define many modern of the chat features found in modern apps, such as reactions, replies, end-to-end encryption etc. These features however, have been implemented by Google in their Messages app and their Jibe backed service. The problem is that these additions by Google are proprietary and only works via Google’s Messages app, so third-party messaging apps can’t get in on the fun.
I believe Samsung’s Messages app may also have access to some(?) of these features if the cellular carrier also uses Google’s Jibe servers for RCS routing, but don’t quote me on that.
As for Apple, I’m pretty sure that if they implement RCS (supposedly this year), it’ll either be the Universal Profile, or most likely the Universal Profile + some proprietary Apple magic sauce for added features. Not sure about E2E encryption though - they would have to work with Google for that to work (for interoperability with Messages), so we’ll have to see how that goes. If I were to guess, I’d say E2E on Apple would most likely be limited to Apple devices. But at least we can expect basic rich messaging features to work cross-platform, so that’s something I guess.
In any case, the main issue remains that Google hasn’t opened up the API/spec for their version of RCS - and the GSMA is seemingly doing nothing about it either, the Universal Profile hasn’t had any updates in the last four years. You can read about the spec in detail here, and if you do, you’ll see that there’s no mention of modern chat features such as end-to-end encryption…
So on one hand, it’s a good thing that Apple is getting RCS this year, but it’ll likely remain either the at the basic Universal Profile level, or some proprietary Apple stuff thrown in, both of which aren’t really ideal.
For the rest of us, none of this really matters unless Google opens up the spec, because why the heck would you settle for a somewhat insecure and limited protocol, when there are far better messaging apps out there, with a greater userbase and cross-platform interoperability?
You should check out Droid-ify! It’s a much more friendlier alternative to F-Droid, and also has more applications by default (gets some apps directly from Github).
I use uBlue and update manually (using a custom alias/script) whenever I get the time, like say during my lunch break or something. Reason being, I actually like watching the update process and seeing what gets updated, watching out for major version number changes or major package upgrades, and if I’m interested I may look up some of their changelogs to find out about their new features etc.
and being forced to reboot
You should be forced to reboot though? And if you don’t want to reboot, can’t you just do an –apply-live? I mean you’d still need to reboot for a kernel update but for the most part, you should be able to use most of your new packages without a reboot. And this holds true even more so if you’re updating Flatpak/container/Nix/pip/cargo/brew packages. And I hope you’re not doing the rookie mistake of actually installing stuff at the ostree layer instead of using Flatpaks/containers/Nix etc.
Distrobox, by default, doesn’t provide much isolation/sandboxing - it’s main aim is desktop integration and filesystem transparency. So if you’re trying to use it for isolation, it’s a bad idea.
However, you can create a new container which will isolate your filesystem and prevent such conflicts, using the –unshare-devsys flag. (if you want FULL isolation though, use the –unshare-all flag).
Then enter the container and install the flatpak app as usual.
I just tested this on Fedora uBlue and an Arch container and it works fine, didn’t have to unmount anything.
Back when I was still on Gnome, I gave this a try and it was great - until Gnome got updated and it stopped working. And then they’d fix it, and Gnome got updated and it stopped working again. So I stopped using it because I couldn’t deal with the constant breakages. I see that they still haven’t updated it for Gnome 45, despite a bug report being opened for it over two months now. It’s exactly because of breakages like this, and extension neglect from the authors, that I’ve stopped using Gnome and switched to KDE.
KDE worked great for me out-of-the-box, so I didn’t install any third-party extensions. The only changes I’ve made is for aesthetics - moved the panel to the top, enabled a global menu and a side dock, for a more Gnome/macOS-style layout.
It looks like you’re still using PulseAudio? I’d highly recommend switching to PipeWire+WirePlumber instead, installing it should make your earbuds work automatically.
ksmbd is still SMB, except it’s implemented within the Linux kernel. As a result, file transfers speeds are improved greatly compared to pure-Samba which runs only in userspace.
The second thing is, you need to check which SMB protocol you’re using, ideally you’d want to use at least SMB 3, anything older than that will be painfully slow.
Finally, I read in your other comment that you’re using spinning disks and a USB dock. That adds significant overheads.
The Ironwolf drive benchmarks starting at 250MB/s and slows down to 100MB/s as it reaches the end of the drive. (spinning disks gradually become slower the more full it becomes.) Now add file fragmentation + filesystem overheads (buffers, cluster size allocation etc) and the speeds could go down considerably.
Then there’s your SATA > USB dock - no dock would ever reach 5Gbps, that’s just false advertising - it’s only mentioning the theoretical protocol speed. In reality, you’d be seeing something like below 100MB/s write speeds for 128k sequential writes, but if your block size is smaller, expect far slower writes.
Combine all of the above and you can imagine just how much slower this whole thing can be.
For reference, see this benchmark as an example, to see what’s “normal” for a simple file transfer to a blank drive with no fragmentation: www.anandtech.com/show/6014/…/3
@agr8lemon The other person mentioned virt-manager, but there’s a much more easier app: Gnome Boxes. It uses the same backend (libvirt/KVM) but it’s much more easier to use - in fact, I’d say that it’s even more easier to use than VirtualBox. For starters, Boxes automatically detects OS ISOs on your drive and allows you to just click on them directly to install it - or you can even choose to download and install a distro directly from within Boxes. Also, when you consider the post-setup phase: there’s no need to install any guest modules/drivers because it’s already built-into Linux distros.
There is a browser extension called “Netflix 1080p”, but in my experience the quality isn’t the same as Netflix’s native 1080p - the quality with the extension is visibly lower (but still better than 720p). And of course, it can’t do 4K at all. It also occasionally breaks, which is annoying.
If you really want to play streaming services at full quality, it’s better to just get a streaming stick like a Fire TV Stick, or a Roku or similar.