突突唧之家

Apart from nvidia-smi, on Linux you can check which processes might be using the GPU using the command

sudo fuser -v /dev/nvidia*

This will list processes that have NVIDIA GPU device nodes open.

I found a great tip in GitHub to compact a VHD file without Hyper-V tools and it works great. The Dynamic VHD don't reduce their size even if the files were deleted from the hard drive, to fix it the "compact" operation is needed. This is included into the Hyper-V tools but this is only available in Windows 10/11 Pro.

There are another way to do this in Windows 10/11 Home, using the next commands:

1
2
3
4
5
6
7
8
9

diskpart
 
# Open window Diskpart 
 
select vdisk file="C:\path\to\file.vhd"
attach vdisk readonly
compact vdisk
detach vdisk
exit

Try this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

\documentclass{article}
\usepackage[T1]{fontenc}
\usepackage{listings,xcolor}

\lstdefinestyle{mystyle}
{
  language=[LaTeX]{TeX},
  texcsstyle=*\color{blue},
  basicstyle=\ttfamily,
  moretexcs={mycommand}, % user command highlight
  frame=single,
}
\begin{document}

\begin{lstlisting}[style=mystyle]
\documentclass{article}
\usepackage[T1]{fontenc}
\newcommand*{\mycommand}{Hello World!}
\begin{document}
  \mycommand
\end{document}
\end{lstlisting}

\end{document}

Hello World,

We have noticed that a lot of people hit the same issue over and over again. When trying to connect via remote desktop protocol (rdp) to the Ubuntu machine, and after providing the credentials in the xRDP Login page, the user will only see a black screen displayed and the desktop interface is never loaded and displayed. This post will basically explain why this happens and how to reproduce the issue.

The "problem" is actually well known and there is really an simple and easy fix for that. So, let's explain the situation.

Reproducing the "Black Screen" Situation

Let's assume that you have performed a successful xRDP installation and you are ready to test your rdp connection to your Ubuntu machine. Let's also assume that you are still logged on into your Ubuntu machine system locally with your user account (which could be called User1). So, you move to your Windows machine (or Linux machine), fire up your favorite remote desktop client and provide the ip address or the hostname.

Since xRDP installation has been successful, you will be presented with the xRDP Login page where you will need to provide the user credentials on the Ubuntu machine. In our example, User1 (yes the one currently logged on locally on the ubuntu machine) account will be used.

If the credentials are correct, you will see your remote desktop session showing a black screen and that’s it !!!!! The desktop interface will never load within your remote session.

Black Screen Situation Explained

As mentioned and explained multiple times, this situation will happen (or can happen) when the same user account is used concurrently locally and remotely. In other words, the problem is related to the fact that the same user account is already logged in locally and a remote connection is attempted at the same time. With xRDP software solution, a specific user account can be logged on either locally or remotely but not both.

The (Standard) Solution

To solve this issue, there is a simple fix. You need to ensure the account you are using to login via the remote desktop client is not currently logged on locally on the Ubuntu target machine. If this is the case, perform a logout operation.

Try again the remote desktop session and you will see that magically, you will be able to perform your remote desktop connection and that your desktop interface will be loaded and made available for you.

To clean all old versions of snaps, try:

LANG=C snap list --all | while read snapname ver rev trk pub notes; do if [[ $notes = *disabled* ]]; then sudo snap remove "$snapname" --revision="$rev"; fi; done

Some checkbox alternatives using bbding, wasysym, or nothing.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

\documentclass{beamer}

\usepackage{bbding}
\let\oldSquare\Square % \Square is also defined in wasysym
\usepackage{wasysym}

\begin{document}

\begin{frame}
    \begin{itemize}
        \item[$\boxtimes$] nothing
        \item[$\square$] nothing
            \bigskip
        \item[\fboxsep0pt\fbox{$\times$}] nothing
        \item[\fboxsep0pt\fbox{$\phantom{\times}$}] nothing
            \bigskip
        \item[\CheckedBox] \texttt{wasysym}
        \item[$\XBox$] \texttt{wasysym}
        \item[\Square] \texttt{wasysym} (\texttt{\textbackslash Square})
            \bigskip
        \item[\small\oldSquare] \texttt{bbding} (also \texttt{\textbackslash Square})
        \item[\small\rlap{\Checkmark}\oldSquare] \texttt{bbding}
        \item[\small\rlap{\XSolidBrush}\oldSquare] \texttt{bbding}
    \end{itemize}
\end{frame}

\end{document}

A proxy act as an intermediary host where you could tunnel your connection through the proxy to access another host. Tunneling your SSH connection via a proxy, among other things, could allow you to access hosts in a private network or under a NAT. As such, a proxy avoids the need to set up a more complex infrastructure such as a VPN.

OpenSSH's SSH client supports connecting through both SOCKS and HTTPS proxy. It is achieved with the ProxyCommand option alongside third-party programs such as nc or netcat.

Steps to connect to SSH server via SOCKS or HTTPS proxy:

1. Create SOCKS or HTTPS proxy if you don't already have one.

2. Test if the SOCKS or HTTPS proxy is reachable from the SSH client's host (optional).

   $ nc -zv 127.0.0.1 2222 Connection to 127.0.0.1 2222 port [tcp/*] succeeded!

   -v Produce more verbose output. -z Only scan for listening daemons, without sending any data to them. Cannot be used together with -l.

3. Use ProxyCommand as option for SSH client.

   $ ssh -o ProxyCommand='nc -X4 -x 127.0.0.1:2222 %h %p' remoteuser@remotehost

   1 2 3 4 5 6 7 8 9 10 11 12 13

   -X proxy_protocol Use proxy_protocol when talking to the proxy server. Supported protocols are 4 (SOCKS v.4), 5 (SOCKS v.5) and connect (HTTPS proxy). If the protocol is not specified, SOCKS version 5 is used. -x proxy_address[:port] Connect to destination using a proxy at proxy_address and port. If port is not specified, the well-known port for the proxy pro‐ tocol is used (1080 for SOCKS, 3128 for HTTPS). An IPv6 address can be specified unambiguously by enclosing proxy_address in square brackets. A proxy cannot be used with any of the options -lsuU.

4. Add ProxyCommand to SSH client configuration file for persistence.

   $ cat .ssh/config Host remotehost hostname 192.168.1.10 user remoteuser ProxyCommand nc -X4 -x 127.0.0.1:2222 %h %p

5. Connect again using SSH client with just the Host name as parameter.

   $ ssh remotehost

Most modern Linux distro uses systemd as init replacement. It is a suite of basic building blocks for Linux distros such as RHEL/CentOS, OpenSUSE/SUSE, Fedora, Arch, Debian, Ubuntu, and more. By default, most distro boot into GUI, but you can change to text or vice versa.

The older version of the Linux distros came with SysV init or Upstart. Such init provided a set of runlevels for text, multi user, and GUI system. However, systemd uses the concept of targets instead of runlevels. This page explains procedures to implement runlevel like config when working with systemd targets. In other words, you will learn how to switch between text or GUI mode using systemd instead of init levels on modern Linux distros.

The --first-time flag causes modprobe to fail if the module is already loaded. That in conjunction with the --dry-run (or the shorthand -n) flag makes a nice test:

modprobe -n --first-time $MODULE && echo "Not loaded" || echo "Loaded"

This also prints Loaded if the module does not exist. We can fix this by combining it with modinfo:

modinfo $MODULE >/dev/null 2>/dev/null &&
! modprobe -n --first-time $MODULE 2>/dev/null &&
echo "Loaded" || echo "Not loaded"

If the state of the package got changed to manual from automatic, you can set it back to automatic in the following manner:

sudo apt-mark auto package_name