thank you for these thoughts, @dianne.dietrich! (and @tim.mifsud!) some of these points we may bring back in larger group discussion, and/or in the SPN Community calls - particularly the metadata/labeling question, which we are absolutely interested in discussing more directly with the Metadata Working Group so we can align where we can with emerging practice (that label used to be called “media type” on the equivalent menus of earlier versions of EaaSI and EaaS, so that’s my bad again for not catching the inconsistency in the testing instructions - I’ve updated everyone’s Google docs again to say “Physical Format” for future reference or anyone who hasn’t had a chance to go through the testing yet!)
Further responses for now, and I will find ways to repeat some of these:
-
No, there is currently not a way to transfer files generated within an emulated Environment to the host computer in the EaaSI interface. I know the OpenSLX team has made this possible with EaaS in general but we have not had the chance to develop the functionality specifically for EaaSI. I will start a “feature request” thread in the Forum - it would be very helpful to get upvotes from others in the community and also to get details on how folks would like to see this implemented (e.g. should it be related to user permissions, with only Admins able to export files or such?)
-
The “Windows 95 C (OSR 2.5)” is not visible right now because of the issue Natalie reported at Can't "Change Resource Media" - using the Windows 95 B environment is indeed a good work-around for the moment. I believe the only difference is that the “C” release had USB capability - in some guest Environments USB capability allows for improved/slightly more precise input using QEMU’s emulated USB tablet or USB mouse devices (instead of the default emulated PS/2 mouse). However, for whatever reason I haven’t noticed that particularly works for Windows 95 B vs. C, even with USB drivers in the C release, so that’s a bit moot.
-
Yes, ultimately we hope to include some “help text” fields that display in the interface next to a running emulation (in that part of the interface where there’s currently some dummy/placeholder data), where users can see or add notes about OS or other guest software compatibility, like CD-ROM support, that might affect loading resources into that environment. There are a number of EaaSI features that depend on relationships like that (enabling “Connect to internet” requires TCP/IP stack support and configuration in the guest OS), so until there is a place for descriptive or free-text information associated with environments in the interface, the best I can do is note these concerns in the User Handbook and keep at it answering such questions and getting folks more comfortable with the underlying tech.
-
If you click on your user name at the top right of the screen and select “Node Preferences”, you should have the option to select your keyboard mapping (e.g. “Macbook/Macbook Pro”). This is another old label that should be changed asap, I believe the setting is user-specific, not node- or org-specific anymore. That may assist with mapping Mac keyboard input to something the emulator/DOS understands, although I am not certain what keys specifically PgUp/PgDn would map to! I’ll try to investigate that.
-
Noted re: automatically regaining control of your mouse instead of having to manually press “Esc” even after an emulated OS is shut down. I’ll file a ticket to put that in the UI development queue!
-
I highly recommend exploring the Internet Archive’s Shareware CD-ROM collection in general to find stuff to blow off steam in EaaSI
-
You are on the money that “Software” and “Content” are a distinction for how these resources are handled by the EaaSI service, not how they’re handled by the emulators. The expected behavior, in a nutshell, is that Software is shareable to other orgs/nodes in the Network (currently via Environments, though we are working on the ability to share Software resources directly, so nodes can pass around installation media); it is assumed to be a dependency, or tool to open and render Content correctly. Content is assumed to be collection items or the thing you’re trying to get to as a digital archivist/librarian/curator/preservationist - which could itself be executable software (little “s”). The intent is that you will never be able to click “Publish to Network” on a Content resource.
The second EaaSI Training Module was intended to elaborate on this distinction. As digital objects, Software and Content resources are treated the same by the system: they can be a single file or collection of files, they must have a defined Physical Format so the emulators know how to mount and behave with them, they could be executable programs, or not. It’s an entirely user-defined distinction of what the files or image contains and your ultimate goal with it in the system.
The “Import Resources” menu should likely carry more of this information, so it is present in the interface itself without needing to consult external resources like the Training Modules or Handbook.