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.

In VisualBasic “true” would be represented as -1 when converted to an int because it’s all 1’s in twos complement.

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).

My dad used to put them on the cars he built.

That’s pretty rad.

I’ve got a RPI running a full-screen ‘kiosk’ view from homeassitant that turns an external display on/off based on a motion sensor.

So basically it’s showing current temperatures, thermostat control, etc. but I have the display turn off after X minutes of no movement and turn on when there has been movement so it’s only on when you’re in the room.

I have an alias set up and SDKs enabled. The experience is indistinguishable from a regular install.

That’s not indistinguishable - that’s you working around the problem of running flatpak run some.domain.IForget(which - BONUS is case sensitive which is awesome) to run neovim.

Snaps install a binary you can run. Flatpaks make you remember the 3 part domain to run things. So you setup aliases after installing things to run them, and if you uninstall them you need to remove your aliases. It’s a complete own-goal by the flatpak developers that this mess exists and is completely unnecessary. Simply providing an option to create and manage a script in .local/bin or something would be all it takes to make flatpaks usable from the CLI in a way that isn’t obnoxious.

Problem with all this is we get shit like flatpak which is unsuitable for use from the cli. GUI first bs for people who can’t be arsed to learn the very basics of the console.

Call me elitist is it makes you feel better, but not all Linux users are morons and can handle a little console use.

Running cli apps like neo vim from a flatpak is frustrating… “flatpak run com.something.neovim” is just the worst way to handle things. Complete deal breaker.

It’s a very difficult problem to solve.

Different architectures are more than just translating op codes. They have different ways to address memory, different types, sizes and number of registers. Compiled binaries use offsets within the code to jump, loop, etc. which all changes when you start changing instructions. It’s much easier to emulate the platform at runtime.

I don’t want an OS designed for idiots - that’s what IOS is and it’s a shitty walled-garden because it has to be.

I mean - IOS exists for you friend. It’s not a superiority thing, it’s that you’re trying to use the wrong OS. Back to the walled garden. It’s safe there.

And if you want to whine about needing to type and use a CLI then you can fuck right off back to IOS.

It’s not though. I’m not saying they can’t try to use it, but they’re looking for “free Windows” not “Linux”.

I’ve heard this complaint since the '90s. Linux has continued to grow and thrive as a “real usable option” in that time.

If you want stupid-user friendly Linux experience get a tablet with Android on it.

Yes you should. It’s part of what makes Linux Linux.

Do we? I didn’t give a solid shit if people switch from Windows.

I’ve seen how deep the rabbit hole of user inability goes. It’s not pretty.

Give them an iPhone, be done.

If using a terminal scares you then don’t use Linux. Back to the walled garden.