... and he goes on to use Metal of all things, instead of Vulkan/MoltenVK, smh. I wouldn't expect the Linux version to see the light of day anytime soon.
Okay so that's different.
nginx only runs the master process as root, but the actual worker processes already run under a low-privileged account called http. If you want to run the master process as well as non-root, you can follow the instructions here: https://wiki.archlinux.org/title/nginx#Running_unprivileged_using_systemd
To restrict access to files, you'd be editing the nginx config file, you can read on how to do that in the nginx documentation, or check ServerFault etc.
But the modern Linux world revolves around containers. There's an official Docker image for nginx that you could use if you'd like, and that'd make it a much more secure - and portable option.
Also, I'd recommend checking the Arch Wiki first for anything Linux related - the wealth of knowledge and documentation there is unmatched, and is useful even if you're not running Arch.
The /etc/sudoers file is what you'd need to edit, and you'd use the visudo command to edit it.
chmod is indeed used for file permissions, but you can also use SELinux or AppArmor for more access/role/action based permissions (aka Mandatory Access Controls) instead of just limiting yourself to file permissions (aka Discretionary Access Control). There's also udev rules (for device/sysfs access) and PAM (Pluggable Authentication Modules). Then there's cgroups and namespaces for process limits and sandboxing. Really depends on what you're trying to achieve.
But is there any reason why you're looking into micromanaging service permissions? Most users, or even power users wouldn't need to touch that stuff at all.
If it's in a corporate environment, you'd already be running something like SELinux or similar and you'd apply a baseline security profile that meets various compliance specs. Very rarely would you have to mess with permissions of a service.
If this is for personal stuff, you'd just make use of multiple user accounts (if it's a multi-user system), or just sandboxing (containers, flatpak etc) to run untrustworthy stuff like web browsers. None of this stuff would require you to touch chmod.
Actually, Edge WebView2 is a separate system component pushed out via Windows Update (can also be bundled with individual apps), and is independent of Edge the browser.
So you can actually uninstall Edge the browser completely if you wanted to, and still keep using Webview.
Of course, it's a different story that Microsoft like to sneak it back in as part of an update or something.
TNG: The First Duty, where Picard lectures Wesley. Such a powerful scene.
"The first duty of every Starfleet officer is to the truth, whether it's scientific truth, or historical truth, or personal truth! It is the guiding principle on which Starfleet is based, and if you can't find it within yourself to stand up and tell the truth about what happened, you don't deserve to wear that uniform."
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?
This is a good example of why vertical videos are cancer.
Here's a much better version: https://www.youtube.com/watch?v=dqcAjxVyJZA
Yep. I ran it on my 450MHz Pentium III back in the day - was incredibly fast and felt so ahead of it's time, especially it's multimedia and multitasking performance, as well as the fast boot speeds. It was my second favorite OS back then.
Am important gotcha is:
Other window managers are only available when using X.org. These changes cannot be made for Wayland sessions yet.
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: https://www.anandtech.com/show/6014/startechcom-usb-30-to-sata-ide-hdd-docking-station-review/3