Bash will cache command locations so it doesn’t need to scan your path too frequently. You can clear it with “hash -r”.

See the other comment about running flatpaks - it’s their fatal flaw imho.

Does the rust code not depend on any C code?

It’s not so simple to say “it’s separate” if there are still dependencies and if the rust code can be broken by C changes.

I’m not defending either position.

correct. but i have hard time suggesting that to a noobie.

Why? It’s just “apt install kde-standard”. It’s one of the benefits of most linux distros that you can switch desktop environments trivially.

You can install other DEs on Pop OS.

How does that increase the risk compared to something like JBOD or overlayfs?

It doesn’t - they all do. I wouldn’t recommend any of them.

Raid 0 increases that risk though.

And it performs very well, especially for gui applications. It even supports multiple monitors for the guest.

For running a desktop it’s clearly superior and “fast enough”. I used it to run my primary development environment for years.

Raid level 0 increases risk of data corruption should there be a disk failure… Don’t do that.

There’s nothing better than virtual box for desktop environments, especially after you install the guest tools.

I don’t know what you mean by “it eats resources” - of course it does, you’re emulating and entire system. What are your expectations?

https://www.loggly.com/ultimate-guide/using-journalctl/

But what does. Be specific. Are you prompted on the CLI or is there a pop-up window that you’re entering credentials into?

What does “doesn’t allow sudo” mean? Did you get an error that provided a reason? What exactly did you do?

Don’t.

They know, the wanted to run xscreensaver though.

It’s really quite simple - but works pretty well. There are 3 components:

Kiosk service

A simple systemd service that starts a kiosk script.

[Unit]
Description=Kiosk
Wants=graphical.target
After=graphical.target

[Service]
Environment=DISPLAY=:0.0
Environment=XAUTHORITY=/home/pi/.Xauthority
Type=simple
ExecStart=/bin/bash /home/pi/kiosk.sh
Restart=on-abort
User=pi
Group=pi

[Install]
WantedBy=graphical.target

Kiosk script

The script in /home/pi/kiosk.sh just starts a web browser in full-screen mode pointed at my home assistant instance:

#!/bin/bash

xset s noblank
xset s off
xset -dpms

export DISPLAY=:0.0 

echo 0 > /sys/class/backlight/rpi_backlight/bl_power

LANDING_PAGE="https://homeassistant.example.com/"

unclutter -idle 0.5 -root &

/usr/bin/chromium-browser --noerrdialogs --disable-infobars --kiosk $LANDING_PAGE

Display service

I have a very simple python/flask service that runs and exposes an endpoint that lets you turn on/off the display. It’s called by a homeassistant automation for when the motion detector senses or hasn’t sensed movement.

Here’s the python - I have this started from another “kiosk.service” systemd service as well.

#!/usr/bin/env python3
import subprocess

from flask import Flask
from flask_restful import Api, Resource

def turn_off_display():
    with(open(backlight_dev, 'w')) as dev:
        dev.write("1")


def turn_on_display():
    with(open(backlight_dev, 'w')) as dev:
        dev.write("0")


class DisplayController(Resource):
    def get(self, state):
        if state == 'off':
            turn_off_display()
        elif state == 'on':
            turn_on_display()
        else:
            return {'message': f'Unknown state {state} - should be off/on'}, 500
        return {"message": "Success"}


def init():
    turn_on_display()


if __name__ == "__main__":
    init()
    app = Flask(__name__)
    api = Api(app)
    api.add_resource(DisplayController, '/display/<string:state>')
    app.run(debug=False, host='0.0.0.0', port=3000)

You can then have the HA rest action call this with “http://pidisplay:3000/display/on” or off.

For apt to install a local file I think you need either a fully qualified path or to use “./” at the start for a relative path.

So “./$1/opensnitch_${1}_amd64.deb”

apt install 1.6.5/opensnitch_1.6.5_amd64.deb 1.6.5/python3-opensnitch-ui_1.6.5_all.deb

Edit: Here’s a better example of what I think you would want:

#!/bin/bash
# Often good to assign a numbered parameter to a variable
VER="${1}"
apt install "./${VER}/opensnitch_${VER}_amd64.deb" "./${VER}/python3-opensnitch-ui_${VER}_all.deb"

Also - when debugging bash scripts it’s often helpful to just put “echo” before the line you’re questioning to see what exactly is being run. e.g.:

#!/bin/bash
VER="${1}"
echo apt install "./${VER}/opensnitch_${VER}_amd64.deb" "./${VER}/python3-opensnitch-ui_${VER}_all.deb"

That will show the the command that would have run rather than running it, then you can inspect it for errors and even copy/paste it to run it by hand.

It’s one of these. I don’t know the chip but I haven’t had any issues with false positives. If anything they’re slightly under sensitive, but not enough to be a deal breaker for my purposes.

I used to do this frequently “back in the day”…

dd will create a complete bit-for-bit copy of the drive and put its contents into a file. All the way down to the boot sector, partitions, etc. Filesystem doesn’t even matter a little.

I used to do something like “dd /dev/sda bs=1M | nc remote.server 1234” and then on the remote server “nc -l 1234 -p > file.img </dev/null”. I was swapping back and forth between Linux and Windows on a work laptop that I was using for non-work related things on the weekend, at conferences, etc.

Wasn’t perhaps my most intelligent moment, but it worked!

Much simpler than that - The motion sensors are zigbee and integrated with HomeAssistant. I have a HA automation that sends a REST call to a webservice I wrote on the PI that then just needs to write 1 or 0 to /sys/class/backlight/rpi_backlight/bl_power.

It requires a near obsessive understanding of the architecture being emulated, but generally the process is “relatively straightforward” (though not necessarily “easy”). A CPU is a relatively simple device compared to the software built on it. Your basic steps are:

1. Read an instruction
2. Perform the instruction
3. Jump to the next instruction

Throw that in a loop and voilà! You have an emulator. Granted I’ve handwaved over a lot of complexity (I don’t mean to trivialize the effort)…

To translate a binary is very different. Compilers optimize output to behave in a specific way for the target CPU that simply may not work on the new CPU. What do you do, for example, if the code was compiled for a platform that had 12 registers but the new one only has 6? You’d need to re-write the logic to work with fewer registers. That’s difficult to do in a way that is generic for any program. An emulator can just present the program with the 12 registers it expects (emulated in memory at the expense of performance).