After the recent conversation about WSL (Windows Subsystem for Linux) I decided to look at what I could shift to run on Finmark from my Windows desktop instead of the Linux laptop I usually use. I see posts that people run the CLI version of ROS on WSL - I haven’t tried that yet. And with the linux GUI coming, I also see that folks are running applications like RVIZ using WSL. But I decided to start simple and just ssh in to my GoPiGo3 to launch ROS locally on the robot. That should work fine for simple programs where I’m not running a navigation stack remotely. I think.
I immediately ran into the problem that I couldn’t ssh into my robot - I’d get a “could not resolve hostname” error when I tried (running Ubuntu 20.04). Some googling found that this issue goes back years, and a lot of somewhat arcane solutions were suggested. However it turned out to be a really easy fix. It just involves turning off “fast start-up”. The steps are listed here: https://stephenreescarter.net/wsl2-network-issues-and-win-10-fast-start-up/
I wanted to post this here in case others have this problem.
I avoid Windows’ “fast startup” like the plague it is as it’s not a “true” startup, but rather is a form of hibernation and, (as far as I have ever known), Windows has never handled restarting from hibernation well.
I ALWAYS set ALL my systems to COMPLETELY SHUT DOWN.
This way a shutdown and restart clears out any cruft and starts fresh.
Windows isn’t the only system to implement a “fast startup” type of startup process which usually begins with a system that is - at least - partially running already, is then suspended, and has its state saved in a kind of a hibernation file.
On restart the system is restarted to some minimal point and then the state of the suspended system is restored. From a purely software point of view, it’s like “unwinding the stack” and restoring the state of a piece of software before it was interrupted. And, (in theory), “unwinding the stack” should restore everything to the way it was before.
The problem here is that a computer system isn’t just software. The system contains hardware - complicated hardware - that can’t simply be “folded up and put away in a drawer” like clean bed sheets.
Preserving a particular hardware context, (which can include status registers, shift registers, stack values within the hardware, the content of any internal cache, the state of the hardware’s internal state-machine, and a whole host of other things), isn’t easy. This internal state of the hardware isn’t transparent to the outside world, nor can it be - think SPECTRE, MELTDOWN, and a whole host of ransomware attacks which used hardware snooping into a system’s internal state to compromise a system.
As a consequence, I have never been satisfied with the way “fast start” works, be it Windows, Ubuntu and it’s derivatives, or whatever else, so I have always recommended a complete and total shutdown.
If a rapid startup is important, I recommend investing in a good SSD instead of the “fast-start” startup process.
In medicine, there’s a saying: “You have to think like the disease to recognize the symptoms”, and I guess that’s why I’m (somewhat) good at hardware - I can “think like the hardware”, which allows a lot of stuff to make sense.
That’s one of my problems with software. . . .
Even a complex piece of hardware does not have a potentially unbounded state. If you are “here” within a particular piece of hardware’s operation, the number of places you can go from there is limited. It might be large, but it’s still limited and can be modeled. In essence, a hardware device can be represented by a finite state machine. The state machine might be LARGE, and the number of potential next-states can be huge, but it is not unlimited.
Software doesn’t have this limitation.
If you imagine yourself, (mentally), as being inside a piece of software, the number of possible places you can legally go from where you are right now rapidly approaches infinity - there is no finite number of states. The only real limitations are battery life, or exhausting a finite hardware resource like RAM or storage.
That is why, (for me at least), writing software is so difficult: The number of possible solutions rapidly expands to near-infinity and becomes massively overwhelming.
The struggle for me is discovering how to limit the problem’s scope without eliminating valid solutions at the same time.
. But the point is well taken.