cockpit: install and enable by default on first boot
I read #1628 (closed), and I agreed that there is insufficient documentation regarding SSH. But I came to the conclusion that cockpit should be our official recommendation for SSH-based activity in FreedomBox, not the terminal. Thus, I feel that cockpit should be enabled and installed during first boot by default.
A few reasons:
-
Many of our users, especially Pioneer users, use Windows, not GNU Linux. Many versions of Windows do not have SSH capabilities by default--users have to install an SSH client like PuTTY. This adds an extra layer of effort and confusion when we tell our users that they have to use SSH to fix a problem. We should tell them that their FreedomBox offers an SSH client out-of-the-box.
-
Our target users--non-technical people--likely have little to no experience with terminals. Most Mac and Windows users, in particular, have never even opened a terminal on their computers. When SSH becomes a necessary remedy to a problem (as it did with the apt problem), we should direct them to a module in FreedomBox, which will be easy to find. We shouldn't ask them to open a terminal on their machine for the first time--that adds an unnecessary layer to the user experience.
-
Installing and enabling cockpit by default provides a reliable fall-back for users when issues arise like our recent apt problem. If a FreedomBox is afflicted by the apt issue, then it cannot install cockpit, or any other apps. This means that users have no choice but to open a terminal (which is a problem for some Windows users, as discussed above). If cockpit was installed out of the box, then a crippling issue like the apt issue would be easier to solve: we could simply advise users to go to cockpit and enter some commands. Every user would have the same experience, leaving less room for human error.
I know that not all problems can be solved by cockpit. If, for example, there is a bug which causes the entire UI to become inaccessible, then users will need to use SSH on a terminal. But my experience has been that there are many problems which require SSH but don't involve the UI going down (e.g. #1363 (closed)).