The initial procedure of entering commands and checking the results took me a couple hours. Writing the post took me about half a day.
I can easily imagine that it is also the case for the other participants. Writing the reports takes always more time than the exercises. I however didn't include that when I mentioned that each episode should take a few hours... I actually didn't even think about it. Baah....
Exactly, very limited space. Another downside of ramfs is that you need to preallocate the size of the filesystem. And if the system crashes you lose all your data. If you have enough memory, RAM filesystems are pretty good for processes that generate a lot of intermediate artifacts (like compiling a large programs). But otherwise the downsides outweigh the benefits.
This is what I thought for the RAM filesystem. As for the next-to-next exercises (in a few episodes that I have not written yet), we will need to simulate collisions and store millions of events (which leads to multi-GB intermediate files), I am not sure that this will work. Except of course if the machine is powerful enough. I nevertheless do not know whether it is worth the test.
Good question. In this case, I don't have access to a graphical display like an X windows or wayland. So no apps like firefox or gimp. But I do have access to an interactive terminal through SSH. And the container runs locally on my computer. So, thankfully, I can see the MadGraph5 process execute in realtime and enter commands as you would normally at a linux terminal.
Then it is then perfect. You can probably have access to the HTML output via a browser like links.
Cheers, and thanks again for this report!