sudneo

I use https://www.chezmoi.io/ for the same purpose of managing dotfiles. There are a bunch of tools to do this that you can pick your poison :)

I think lazylibrarian is user to search and download books automatically. Are you using calibre as in the native tool, or calibre-web?

Ansible is definitely one way to do this. If your machines are VMs, then also building VM images with packer can be the way.

For tmux, vim, etc. You can still use ansible or some specific tool for dotfiles, like chezmoi (there are a bunch). You can even use ansible to run chezmoi!

Oh no, I get it, I was quite scared the first time I messed with it, and I cursed LG plenty for not letting me install safely what I want on my own TV. I found this technique to be quite safe though. You basically uninstall the official YouTube app, then do the loading and you can always remove the app and reinstall the official one.

I hope I didn't sound condescending, I just realized that I had been a bit too quick labeling something easy, while I understand that for some other person reading, using a CLI tool is in itself a new thing. Good luck :)

The procedure to install is very easy, you can also always uninstall it and reinstall the official one, I don't think it's irreversible in any way. Note that I am talking about side loading using developer mode. Rooting the TV via an exploit can brick your TV instead.

Edit: The procedure is basically described in https://webostv.developer.lge.com/develop/getting-started/developer-mode-app.

I realize I said very simple, but I guess it depends on your familiarity with tech and command line tools.

I think the answer is fairly simpler, from my point of view: because NATO is not a military alliance among peers. It is the military arm of the American empire. This allows US to essentially manage the foreign policies of most of NATO members, but it also comes with the cost of being the one paying the bills. Empires are expensive.

I will skip commenting the rest because, well, you are entitled to your own opinion and you can loathe who you want. I would perhaps simply suggest to look at your own country with an outside perspective and realize that if everyone used your same logic, the world will be a more hateful place than already is.

I use https://github.com/webosbrew/youtube-webos on my LG TV, to watch without ads. I have to sideload it via the CLI tools, but it works. Sometimes I have to reinstall it (I suppose some TV update screws up), but for my partner watching without ads is worth the random sporadic breakage.

Thanks for sharing, I was not aware of it, and it worked like a charm.

Some additional benefits also are the management of secrets. In compose you will shove them inside a .ENV file if not directly inside the compose file, while in Kubernetes you can use the secrets resource or even plug in Vault relatively easily. Stateful storage is also better handled. Named volumes are nasty to keep track of, backup and it's not possible to spread them across multiple devices (as in disks) while bind mounts are insecure in general. Kubernetes provides a storage abstraction which is easier to manage.

Obviously the big advantage comes when you want to run stuff on multiple devices to spread the load (or because the one box is saturated), since with compose you would need completely custom and independent setups.

Finally, I would say that running compose makes it much harder to have a monitoring stack supporting your services, since you will need to do all the plumbing for metrics endpoints yourself. And - very last - you can have admission controllers in Kubernetes that prevent certain configuration (e.g. Kyverno with a bunch of default policies), while with compose you need to manually vet every compose file and image (for example, to ensure it doesn't run as root).

That said, compose is perfect to get started and to run stuff on one machine.

If you containerize, the application (malware) will run under the user configured in the image, unless you override it, and in a separate mount namespace, unless you change that, which makes the "alias sudo" trick extremely unlikely.

Even running under a separate user anyway prevents almost fully the attack you mention, unless the separate user has root privileges or the DAC_OVERRIDE capability is assigned to the binary (assigning it requires CAP_SYS_ADMIN).

In short, the attack you mention is a common persistence and privilege escalation vector, which is relatively easy to detect (watch for changes to shell profiles), although preventing it requires some care. I just want to point out that in single-user machines (e.g. personal computers) escalating to root is anyway fairly unnecessary, given that all the juicy stuff (ssh keys, data, etc.) is anyway probably running under/owned by that user.

Vulnerabilities can and are usually found without code inspection. Fuzzing, reverse engineering, etc. At the same time, it is easier to find vulnerabilities having the code to check, but it is easier also for those who want to have them patched. That's why we have tons of CVEs in Windows, iOS etc., and they don't all come from the vendor... Depending on the ratio of eyeballs looking at something to fix and the ones looking at something to exploit, open source can be more secure compared to closed source.

Congrats, very good KB, I have 2 of them!