Thanks! I’ve come across many of Simos’ posts while getting up to speed on LXD. I had previously ended up settling on using the forgotten xdmcp to establish and manage the connections. My next go around will probably use a different approach that is more secure.
My use case for code-server is that I can then access the IDE from any computer allowing me greater flexibility of the device that I code on.
I use LXD (too lazy to move to Incus at the moment) for this exact purpose. It’s definitely nice having a greater degree of isolation between the various projects I’m working on — especially when working with confidential information from clients. Depending on what you’re looking to do there are simpler ways to manage isolation between projects like chroot and nspawn or Nix’s environments. Then again by using LXD/Incus you get that plus lots of other useful tools baked in.
Regarding not getting an IP address have you checked your base configuration to see if dhcp has been configured for the bridge? If that isn’t the issue then all I can think of is that you somehow deleted the interface and should check the container config.
That said the commands provided above are how I usually access the container command line. For coding I use code-server to put VS Code in a browser. I’m sure there are better options and look forward to the suggestions.
Keep going and learning!
Providing more specific information about what isn’t working would help resolve the issue.
The flathub page lists some additional steps that need to be performed to allow virtual input. Did you do this?
I would check system level logs to start like dmesg and syslog.
Someone else might have better tips of what to grep for in the logs. One thing you could do is try to ssh into the system when it’s locked up and check the logs to see what’s being reported during or immediately before the lockup.
Once you get a sense for what’s going on at a system level you can start to look in more specific logs.
Not to be that guy but have you checked the system logs when this happens?
I’d investigate the differences between the installs particularly around graphics and power management. It sounds like your system is getting woken up but it’s hanging at some stage in the process of resuming. You might get lucky and the issue might show up in the logs if you’re willing to investigate them.
When I’ve run NUCs in the past I’ve had issues with external nvidia GPUs dropping off the bus when resuming from suspend. To “fix” the issue, I ended up limiting the power state to S2 or S3 so that the graphics card was kept on the bus.
Do you know what display server, DE, power management service you were running on both? If the logs don’t turn anything up you can always compare the configs too to see how they’re suspending/waking the system.
If you use steam the remote play/steam link is super easy to set up. If you have steam on both devices, are on the same network, and are logged in to the same account on both devices then steam pretty much handles everything for you so all you have to do is click play on remote pc.
Those are the devices I was thinking of. If my understanding of these devices is correct, they require a direct device to device connection and would not work with packet switching devices like a switch or router. That means you would need two Ethernet lines running from your office to your living room in order to get both usb and HDMI. In addition, you run into the bandwidth issue I was describing earlier where the HDMI signal caps out at a maximum of 1080p60 and it could be lower if the signal degrades enough over the long distance.
In my opinion your either better off going with a single fiber optic cable that can handle both usb and display (like thunderbolt or one of the newer usb standards) or using a cheap device that supports game streaming. Using a single cable is fairly expensive as the cable itself isn’t cheap and could require ancillary hardware. It could also necessitate snaking cables in your walls. As for game streaming the cost of entry can be pretty low as you primarily just need something that can decode the stream for the tv. An old laptop (I’ve even had some success with an old acer chromebook) or even a phone might be sufficient for you to give game streaming from your pc a try to see if you like it and if the latency is sufficient. My vote would be to cobble something together for free to try out game streaming to see if you like it and then go from there. RPi3’s are capable of running game streaming and don’t break the bank.
Would you be able to post links to the devices you’re looking at to get some context?
If these devices are what I’m thinking of then they don’t typically run through a switch/router. Instead, they’re meant to run directly connected from device to device as if they were one long cable. The biggest downside to these types of devices is the latency and bandwidth limitations they introduce. Some of these HDMI over Ethernet devices cap out around 1080p60 (maybe even as low as 30 hz) and can add noticeable latency. With that said, I don’t think the usb over Ethernet should introduce a noticeable delay and think that one is fine — if it’s what I’m thinking of.
Have you considered using a fiber optic HDMI cable? I have had success running a 50’ fiber optic DP1.4 at 5120x1440p120 with no noticeable latency (though I don’t play a lot of FPS) that I bought off Amazon for like $80. If you could stretch your budget a little more perhaps the usb over Ethernet (or fiber) paired with a fiber cable for HDMI might suit your needs.
Alternatively, if you aren’t gaming at super high refresh rates and latency isn’t super critical, then streaming to a device connected to the tv in your living room might be a better choice. I’ve run both a raspberry pi 3/4 and an nvidia shield using steam link and found that to be great when gaming from different rooms in my house. Using a wired connection end-to-end the network latency is usually within the frame-time when playing at 60 fps and hasn’t been noticeable for me (again I don’t play a lot of FPS games).
I wonder if the lower suicide rate is due to the fact that the individuals with tinnitus actually seek medical attention for it and, as a side effect, get treated for additional health problems as well.