I wanted to upvote you, cause I am not psrt of the anti-ai mob, but then I read you last sentence and the rest of this thread and holy fuck are you unlikable and unbearable.
The list of functional differences is too long to write here. I'm sure you can ask some llm to do the google search for you and it will shit out an ungodly amount of differences.
But I'd say roughly they are about:
how you configure it (sudo has a much more complex and expressive syntax, doas needs many more lines for the same result)
how it preserves env variables (sudo has more options for that, it excludes some by default while keeping others and can spawn subshells differently with -l -i)
how it does persisting authorization over some period of time :
doas on OpenBSD caches via a kernel API.
The slicer69 portable doas port has no persist on Linux/FreeBSD - you re-enter your password every invocation.
OpenDoas implements persist via timestamp files, similar to sudo but with fewer tuning options.
How can you grant access to an account to write remotely, but also protect the data from this account?
So I was thinking that the account should not be able to delete the filesystem in an unrecoverable way. Like overriding the current fs with random data or an encrypted fs and filling it etc.
Like I said on a Hetzner storage box, multiple users get access to the same system, but each one only has file editing commands, not fs editing and they can only access their assigned directory. So if the system does scheduled snapshots (outside of that user's scope of access) there is no way for a user to delete the files beyond recoverability. (no matter if their own files or other users files).
The user can still delete their own data. But because the fs is cow with snapshots (like btrfs) and they can not touch that, the data can be recovered easily.
I think you could do it somewhat like hetzner does for their storage boxes. You get an account that has read and write access to a directory and nothing outside. The accound can only run a limited set of commands, like ls, cat, nano, rsync etc. but has no access to commands that modify the filesystem.
Then you can use a copy on write fs like btrfs and make scheduled staggered snapshots.
I usually do 1x per year, 1x per month of current year, 4 per week of current montg, 7 per day in current week.
I have no clue what they use to limit the user accounts like that btw. but maybe that gives you a new jump off point for further research.
Rustdesk is what I use for tech support for my family. By default it uses the rustdesk official server for the handshake and holepunching or whatever, but you can also selfhost your own if you want to.
But I want to migrate to some kind of hardware web kvm like nanokvm, cause sometimes their pc doesn't boot and walking them through bios settings over a shaky videocall is a nightmare.
Think of window functions as a two-layer operation:
Layer 1: Produce all the rows (FROM, WHERE, GROUP BY, HAVING)
Layer 2: For each row, peek at its "neighborhood" (partition) and compute something
The result of Layer 2 is just another column added to each row. Nothing collapses, nothing gets removed. You just get extra computed values based on context and that context is what PARTITION BY, ORDER BY, and the frame clause define.
I think the interface will be difficult to print. If the underside is smooth, the non sticking material might not stay in place. If the underside is rough ... well then you have a joint with at least one rough spot in it's rotation.
Thats just from thinking about my experience with using pla with petg supports (and vice versa) so it may be better than I expect.
Depending on the usecase, I think it might work.
But I think it's easier to print a joint in place from a single material and then "snap" it so it moves. Or design something where you print the parts seperately and then assemble.
The website looks AI generated to me as well. The style and especially the purple really give it that token AI look.
(Just pointing it out, not in a negative way, not implying anything)