Welcome!
A bit of an ancient
web2.0 design,
Couple lines of code,
thoughts, photo and a charm. Read more
Examples
ready to use. Go to category
Electronics
micro, radio,
and usual. Go to category
Photo
From different categories. View category
Very, very often you have to deal with the need to use a certain version of Python, for example, for torch, or for something specific.
Using conda or Docker with nvidia-container-toolkit and then setting up images like nvidia/cuda:13.0.1-runtime-ubuntu22.04 feels counterintuitive to me, even though I’ve done it many times.
And an additional packages have to be installed in the container.
It’s easier and more convenient to compile everything on the host system, but at the same time prevent contamination of the entire system with third-party libraries and executable files.
The following is an example of building multiple Python versions for the verpy group only, which is a bit more convenient than installing for just one user.
ai - an arbitrary user from whom the compilation is performed.verpy - the group that will be allowed to use these versions.mkdir /opt/openssl
mkdir /opt/python
groupadd --gid 42398 verpy
usermod -aG verpy ai
21/November/2025 kubernetesk8slxc
This example shows an installation over LXC, while for any more or less serious use this is completely unacceptable and requires using KVM with additional security measures.
And besides, installation on KVM will be much, much easier.
LXC does not provide adequate security because, for proper operation, it requires mounting the /sys and /proc partitions from the host, which are accessible to all LXC instances.
Furthermore, this example requires using a PRIVILEGED virtual machine.
However, LXC allows relatively easy setting up a testing infrastructure without the overhead associated with KVM.
So some aspects in this example will only be related to the setup in LXC.
First, let’s make preparations on the host system.
nano /etc/modules
nano /etc/sysctl.d/35-lxc-kubernetes.conf
1 2 3 4 5 6 7 8 9 10 11 | |
Everyone knows about the limits on the number of connections from one IP (IP-based), but what if we want to limit the number of connections to a certain API per authorization token?
And it doesn’t matter how many different IPs will be used.
Part of the nginx config:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | |
12/January/2024 gdm3xorgkvmsecurity
Abstractly.
There is some software that needs X’s.
Download, install, launch - enjoy.
But here’s the problem: I don’t want to run software (absolutely everything that is not included in the standard debian repository.) like this on:
In addition, a browser for regular web surfing and a browser for client banking are not the same browser, user, and sometimes even system.
We will not consider points 1, 2, 4 now; we will talk about X.
In debian, with standard system settings, LightDM is used as the default display manager.
You can enable listen tcp in it, but it runs Xorg processes as root.
In gdm3, on the contrary, by default, it launches Xorg from the user who logs into the environment, but the ability to enable listen tcp was broken.
More precisely, they left the ability to disable nolisten tcp,
but not enable listen tcp.
To do this, you need to edit the wrapper over X.
We have a laptop with intel wifi onboard which sometimes failed due to overheating, or due to long-term uptime, or channel load / pps, or whatever.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | |
Basic or simple option just reboot system. But when (always) you have million open windows and million shell tabs with runned scripts over mounted partitions, it’s not a vary good option.
Reload failed wifi...