Chang Qian (Fred) slackingfred

Create a Wi-Fi hotspot on Linux using `nmcli`

Original post : https://unix.stackexchange.com/a/310699

nmcli con add type wifi ifname wlan0 con-name Hostspot autoconnect yes ssid Hostspot
nmcli con modify Hostspot 802-11-wireless.mode ap 802-11-wireless.band bg ipv4.method shared
nmcli con modify Hostspot wifi-sec.key-mgmt wpa-psk
nmcli con modify Hostspot wifi-sec.psk "veryveryhardpassword1234"

$ openssl speed -evp aes-128-gcm | chacha20-poly1305 の結果を集めるスレ

AES-CBC が早いけど、AES-GCM/AES-CTR が遅かったり、Ryzen が爆速だったり、 ChaCha20-Poly1305 が ARM で早かったりするという噂の真相が知りたいです。コメントに適当にべたべた結果を貼ってください。

ちなみに Apple M2 おかしいくらい早いです。

CPU 情報はできれば詳細なのがほしいです。

OpenSSL のバージョンは 3.1 系の最新版でお願いします。

[WINDOWS] How to enable auto-signing Git commits with GnuPG for programs that don't support it natively

This is a step-by-step guide on how to enable auto-signing Git commits with GPG for every applications that don't support it natively (eg. GitHub Desktop, Eclipse, Git Tower, ...)

Requirements

Install GPG4Win: this software is a bundle with latest version of GnuPG v2, Kleopatra v3 certificate manager, GNU Privacy Assistant (GPA) v0.9 which is a GUI that uses GTK+, GpgOL and GpgEX that are respectively an extension for MS Outlook and an extension for Windows Explorer shell
Install Git for Windows: so you can have a *nix based shell, this software is a bundle with latest version of Git which use MINGW environment, a Git bash shell, a Git GUI and an extension for Windows Explorer shell (Make sure your local version of Git is at least 2.0, otherwise Git don't have support for automatically sign your commits)
Verify

(NB: adapted from this Ask Ubuntu thread -- tested to work on Ubuntu 16.04 LTS through Ubuntu 22.04 LTS (Jammy).

Unlike using VMWare Tools to enable Linux guest capabilities, the open-vm-tools package doesn't auto-mount shared VMWare folders. This can be frustrating in various ways, but there's an easy fix.

TL;DR

Install open-vm-tools and run:

sudo mount -t fuse.vmhgfs-fuse .host:/ /mnt/hgfs -o allow_other

海外兔

According to https://xfs.org/index.php/Shrinking_Support :
"Currently XFS Filesystems can't be shrunk."
You need backup the data and recreate the file system to shrink it.
But if you have a big xfs filesystem with not too much space used, For example, a 2T xfs volume with 100G data.
And you can take some risk to lose data. Here is a way to shrink it without using new space.
The idea is:
1.temporary reduce the logic volume size, you can still read from xfs filesystem even after the partition or volume is shrunk if the real data is not wrote at the shrunk part
2.create a new volume
3.copy data

	# one or the other, NOT both

	[url "https://github"]
	insteadOf = git://github

	# or

	[url "git@github.com:"]
	insteadOf = git://github

	@echo on
	REM checked for Windows 10
	REM fork from https://gist.github.com/theultramage/cbdfdbb733d4a5b7d2669a6255b4b94b
	REM you may want full list https://gist.github.com/raspi/203aef3694e34fefebf772c78c37ec2c

	REM SET attrib=+ATTRIB_HIDE
	SET attrib=-ATTRIB_HIDE

	REM Hard disk burst ignore time
	powercfg -attributes 0012ee47-9041-4b5d-9b77-535fba8b1442 80e3c60e-bb94-4ad8-bbe0-0d3195efc663 %attrib%

	Vocabulary size 2544
	Sequence length 20
	_________________________________________________________________
	Layer (type) Output Shape Param #
	=================================================================
	embedding (Embedding) (None, 20, 50) 127200
	_________________________________________________________________
	lstm (LSTM) (None, 20, 100) 60400
	_________________________________________________________________
	lstm_1 (LSTM) (None, 100) 80400

	NVIDIA Driver Version: 455.23.05 CUDA Version: 11.1

	Credit: r4d1x
	For benchmarking the card and allowing me to release the benchmarks here

	There are a handful of algorithms failing, mostly appears related to SCRYPT and
	is liking a tuning issue or small driver issue that we will need to take a look at.
	Otherwise, seems fairly stable.