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?
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.
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).
Just so you’re aware, Gitea was taken over by a for-profit company. Which is why it was forked and Forgejo was formed. If you don’t use Github as a matter of principle, then you should switch to Forgejo instead.
There really isn’t any popular alternative to Flash today, and I think that’s kind of a bummer.
WASM is looking increasingly good these days.
Have a look at egui for instance, and just see how fluid and perfomant it is on all platforms - and that is running without using any insecure/clunky/buggy plugins.
The only issue (with egui) is that it’s basically Rust so it’s not exactly newbie friendly, but that’s just a tooling issue. Hopefully in time we can get more newbie friendly tools, and with increasing number of apps using HTML these days, we might just see something as easy to use as Flash soon enough. :)
As for the –apply-live, I use it on occasion but I don’t want to rely on it for system updates (if that’s even possible).
As I said before, it does work for system updates, the only exception being the kernel. The –apply-live flag was added for that exact reason, to avoid the need for an unnecessary reboot.
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.
Audio works. Not sure how though, –unshare-devsys is supposed to not share the hosts devices, but I guess audio devices are an exception.
The full isolation flags are:
<span style="color:#323232;">--unshare-devsys: do not share host devices and sysfs dirs from host
</span><span style="color:#323232;">--unshare-ipc: do not share ipc namespace with host
</span><span style="color:#323232;">--unshare-netns: do not share the net namespace with host
</span><span style="color:#323232;">--unshare-process: do not share process namespace with host
</span><span style="color:#323232;">--unshare-all: activate all the unshare flags below
</span>