Requirements for Requirements

This text is not exactly mine. It is a very high-level abstract of what a book Requirements Engineering by Elizabeth Hull, Ken Jackson, Jeremy Dick, 2005 has to say on the subject of requirements for requirements.

So, how can we understand that your requirements are ok, or not ok? If they are another source of quality risks? To answer these questions, I've prepared some sets of criteria that we can use for assessment:
 

Fix Invisible Drive for Linux Installer on Windows Notebook (ASUS VivoBook S14)

As it turns out it is not unusual to try to install Linux on a Windows notebook and notice that your installer (such as Unetbootin, for instance) can not locate any hard drive. The easiest way to fix it is to switch to legacy mode (Internet claims that legacy mode should be supported under any circumstances), but it is not always easy to find.

I got myself a new ASUS VivoBook S14 and there were no legacy option (it was in place on my old ACER Aspire V). I had to google around, try switching things on and off, and here is what changed things to the better:

-- get into BIOS menu (F2);
-- switch  to Advanced;
-- open SATA Configuration;
-- permanently switch it to AHCI.

This will make your hard drive visible and goodbye Windows.

My configuration:
ASUS VivoBook S14
Ubuntu 19.10 on Unetbootin USB stick
Temporary enabled boot with USB

Docker commands vs Docker life cycle - Basic level

Earlier I noticed that there's one problem with Docker support documentation. Unfortunately, while it is possible to find out the very basic scenarios in its Get Started section, you need to dig through the Internet for hours to find information about use cases. Use cases is an answer to the question "What are we trying to do here, anyway?".

So, I started to collect this information for myself and pair it with command sets. Below you can find a use case for setting up a docker image and performing some basic commands on it. I shall extend this collection later, if I'm lucky.