vaalla

Probably is a camera.

Probably airforce.

There are interviews with Ukrainian soldiers who said they stay away from civilians so that when Russians bombard them the civilians will not be affected.

I think the combat style and priorities are a bit different so a comparision cannot be made in this case.

It’s hard and expensive. The us-mexico border has the same problem and US spends like crazy to find tunnels. If the tunnel is bellow 5-10 meters I think it’s almost imposible [1]

In Gaza from what I heard they also only use hand tools to avoid making a lot of noise.

Drivers from 3rd party. Didn’t work on phone development, but was part of a company that developed setup boxes.

We will get a kernel from broadcom with all the necessary drivers that was tested for that configuration. Updating was very hard without support and might cost a lot.

Probably its just a snapshot at some point, with maybe downloading new stuff when its published. At least thisbis how i’d do it.

Will have more when the sun explodes.

I mostly write rust now, but this workflow was finetuned over years. Use 2 terminals each on a diferent monitor, one runs neovim and the other is for building/running. If the project is a bit more complex, I will run it in a docker container( maybe mount the /etc/shadow and frieds so all artefacts are created using the same user as in the outside) . Developed a bunch of tools over the years to optimise this:

• a ‘package manager’ in bash so I have a folder for each project/context. One for work, one common, one for the server stuff like this. All are in PATH.
• parterm - remote control for the terminal so i can start a build from neovim in a different terminal.
• ‘ndock’ - at work I use a bunch of branches, this script will set up a few envs and then start a docker in a folder coresponding to that branch.

At my old job had to work on a remote vm so I setup sshfs for a while, but was slow and just moved all my tools there.

I have a pattern where i put all my projects in ~/dev/<project><branch> and all info related to a task in ~/dev/<project>/bugs/<issue_nr>. This is usefull because I can have scripts the work similar for different projects with small changes. For example to run my binary with the config for a issue i just do

ndock <branch>
nr <issue nr>

This will start docker or connect to an existing one for that branch if available, compile the code, run my binary with the config present in the bug folder. In the last few month started running it with rr to be sure i can debug any random issue.