Accessing a Linux machine from Linux/Windows via RDP is not fun.
Accessing a Windows machine from Linux/Windows via RDP works excellent - I use Remmina on Linux, but there are ofc lots of alternatives, as usual.
Points on accessing a Linux(Fedora/KDE Plasma) machine via RDP:
- as I understand it, you cannot open a new session, you can only access an existing one -> forget about a headless machine, it will have to render its DE into to void if you want access it via RDP. The work-flow is more like VNC than RDP.
- X11 has problems, Wayland is definitely worse. Queue the people who will tell me/you that it works fine them. My last attempt on Fedora ended with a "working" setup. Working in quotes, since I had to accept/allow every incoming connection on the host machine (in a pop-up window which auto-hides after a few seconds and did work ~60% of the time), making it useless for the intended use case. You can workaround this by SSH'ing into the machine and accepting the connection somehow, but I gave up at this moment.
- there is also some fun to be had regarding display resolution and "session passwords", but compared to the fun with Wayland "security" and portals, its manageable
"1.Serialize the entire scene, compress the data, and pass it to the joining client. We already do full scene serialization for quicksave and quickload, so this is possible, but the files are large: 30-50 MB is common, often more, so transfer would take a while.
[...]
3. Record the deterministic command stream, pass it to the joining client, and have that client apply all changes to the loaded scene before joining the game. The amount of data is much smaller than in option 2 since we’re not sending any voxel data, but applying the changes can take a while since it involves a lot computation.
Once we started investigating option 3 we realized it was actually less data than we anticipated, but we still limit the buffer size and disable join-in-progress when it fills up. This allows late joins up to a certain amount of scene changes, beyond which applying the commands would simply take an unreasonably long time. "
So [1] is not an option for players who want to do it that way?
Part of the problem with [1] is that you still end up needing [3] anyhow, because even if you've got a fiber-to-fiber connection, while the transfer was occurring the game world has moved on and you'll need to replay that anyhow.
But if you've got a solution for [3] that works completely correctly anyhow, then writing lots of code for [1] becomes redundant to that anyhow, even with save/load code sitting right there. Might as well start from the beginning and replay it anyhow.
One of the things I will often do that I sometimes have to explain to my fellow engineers is bound the rate at which we'll have to handle certain changes based on what is making them. If you know that you've got a human on the other end of some system, they can only click and type and enter text so quickly. Yes, you still need to account for things like copy & paste if that's an issue for your system, where they may suddenly roll up with a novel's worth of text, but you know they can't be sending you War and Peace sixty times a second. You can make a lot of good scaling decisions around how many resources a user needs when you remember that. The bitrate coming out of a human being is generally fairly small; we do our human magic with the concatenation of lots of bits over lots of time but the bitrate itself is generally small. For all that Teardown is amazingly more technically complicated than Doom, the "list of instructions the humans gave to the game" is not necessarily all that much larger than a Doom demo (which is itself a recording of inputs that gets played back, not a video file), because even Doom was already brushing up on the limits of how many bits-per-second we humans can emit.
There is always the option of force pausing the game to all clients until the joining client is fully in sync. Age of Empires 2 does something like this when a player that was dropped later rejoins the game. You can even have a screen showing how synced each player is and an ETA based on their download speed, with the ability to chat and even kick a player...
Obviously that won't scale if you intend to have dozens of players constantly joining a server rather than a "friends only" (or whatever more constrained scenario) where players only occasionally join mid game.
fme, it's only kind of inconvenient. By the time the scene gets to the point where join-in-progress is disabled it's complete chaos anyway. Might as well restart the scene.
That said I haven't played any of the more intricate mods out there, but I can how it would become more of an issue.
Sounds like you didnt sign a contract with an electricity provider and therefore are put in a fallback ("Grundversorgung") contract with the grid provider, which in 95% of cases is a bad deal for normal consumers.
You are free to make this choice, but if it bothers you enough to complain about it, it should bother you enough to invest 30 minutes and sign a contract: https://www.verivox.de/stromvergleich/
> When you Google "NanoClaw," a fake website ranks #2 globally, right below the project's GitHub.
Unfortunately, the fake website [.net] is also #3 on Kagi, and #1 on Duckduckgo.
On Kagi, the Github is #1 and nanoclaw.dev is #4, but only if you count "Interesting Finds".
On Duckduckgo, the Github is #2 and nanoclaw.dev is nowhere to be found.
Trash Headline. He was not part of the Nuclear Exit, therefore he can not "admit" a mistake. He thinks it was and desperately wants it to be a mistake, no doubt.
I’m referring to the demo in the original article. The mouse pointer moves rather rapidly onto the inside of the window. You can just about see the resize pointer flashing as the user does so. I don’t think I ever attempted to resize a window with such erratic mouse movements. Approaching the corner at reasonable speed shows the resize pointer where expected.
> I’m referring to the demo in the original article.
The article from noheger.at? I am also referring to it. My guess is that the pointer speed is exaggerated due to zoom of the gif, and/or that we are using the mouse in different ways.
Yes, that demo. You can clearly see the resize pointer flashing briefly, but the user continues aiming right inside the window. I’m not sure why he’s not stopping when the resize pointer appears. It seems erratic.
Arguably the feedback via the cursor change is feedback to help you learn, like the icons that appear in the close / minimise / zoom, or stickers on the keys of a musical instrument. You pretty quickly learn which one is which, or you can't use them effectively. At some point you'd hope that common actions become muscle memory.
So if it was something that was learned whilst using the previous version, and worked, I'd argue it wasn't 'erratic'.
Points on accessing a Linux(Fedora/KDE Plasma) machine via RDP:
reply