They're on a Ubuntu system, so don't they normally see a $ instead of a #, and have to sudo everywhere?.
Only if they are unpriveleged users, otherwise:
$ sudo su
password: -user password-
#
To be fair to the hardworking acquisition troops in DoD, the Predator and Reaper were demonstrated and fielded through a short-cut process for fielding new capabilities quickly. When the normally thorough system design process is "streamlined" (or bypassed) to rapidly field a new capability, bad stuff can and does happen. Thus, the acquisition axiom, 'When you want it real bad, that's usually how you get it." As an example, of all the recorded predator losses through 2009, only ~3% were lost to enemy action (i.e., shot down). That means that rest crashed for other reasons like design flaws, equipment failure and pilot error. Not exactly what they projected for expected losses.
Commanders in the field are willing to accept risks to get a capability faster, but those risks are not always easy to predict, as this virus issue shows. For the GCS, the virus updates, map updates and any other software updates would have to be transferred from Internet connected systems. Media screening procedures were certainly put in place. It is a sub-opitimal solution, but not a tremendous risk given the system's isolation and controls in place. This event was, most likely, a process violation that led to an MBR infection, vice a system failure. In some cases risks are easier to predict, such as lack of logistics support for newly fielded systems that have not gone through a detailed logistics analysis and planning phase. The loggies then have to play catch up on supply chain, maintenance training, sparing levels and supportability planning.
To be fair to the accelerated processes, they meet a very real need to improve mission capability quickly. Balancing risk vs capability must prioritize those that choose to go forth and fight the war.
"Your mother was a hamster, and your father smelt of elderberrys!" -- Monty Python and the Holy Grail