The aim: to make checking system resource usage a little more accessible, ideally with historical data thrown into the mix for some added context.

Two years on and the fruits of that redesigned effort are finally available to sample, albeit through a new app called (aptly enough) GNOME Usage.


A new version of Usage is set to be released alongside GNOME 3.28 in March, and, accordingly, will be available to install in Ubuntu 18.04 LTS.

But how’s the app looking?

Well, don’t get too excited. Despite being in development for a while the app doesn’t quite deliver on the lure of the early mock-ups. For instance, it doesn’t provide historical data (yet) or offer any stats on power usage.

Effectively Usage 3.28 only tells you what your computer is doing right now — a job the regular System Monitor app and CLI apps like top can do too.

That said, it’s nice enough. Even at this early stage it’s clear to see that Usage is well placed as user friendly alternative to GNOME System Monitor. Through the use of colorful graphs you can quickly see how system resources like RAM, CPU and network are being used.

GNOME Usage wants to relay all of the information the GNOME System Monitor tool does, but in a more modern and easier to parse manner, with less emphasis on interfering with processes, and more on inferring what they’re up to.

This first version is able to relay the following information:

  • Processor Usage
  • Memory usage
  • Network usage
  • Storage usage

It also lets you:

  • Filter processes by name
  • Browse & visualise storage

GNOME developers will hate me for saying it but Usage sort of reminds me of a mobile system resource app in that it’s designed to relay system information in a manner that’s instantly digestible. CLI tools like top and other process monitoring tools aren’t indecipherable, but understanding what they show requires a couple of minutes of orientation.

Usage is promising and I look forward to seeing it mature.

(Of course, nothing competes with the sheer system monitor bling of Deepin System Monitor!)
Reiteratium Disclamerium

Now, lest anyone misunderstand: Usage is not replacing System Monitor. Development on System Monitor is continuing (indeed, there are nice improvements coming in GNOME 3.28). They are two apps that do similar things, but in different ways, aimed at different users.

Got it? Get it? Good.
Install GNOME Usage on Ubuntu

If you’re running the Ubuntu 18.04 daily builds then you can try Usage out for yourself by installing it from Ubuntu Software.


SHTFPlan.com的Mac Slavo最近在论坛里编辑贴出了Chris Kitze发布在Before Its News的帖子。原帖在生存者论坛里,是一个叫塞尔克的人1992年间波斯尼亚危机中与其家庭长期SHTF状态下生存的第一手报告。许多论坛成员问了塞尔 克各种各样的问题,后者很热情的回答了。本文是对这些问答的的编辑本。

在这个梗概里,塞尔克描述了他如何在一个没有电力,燃油或燃料,自来水,食物分配,传统商业,的城市里生活了一年的。他们的货币已经全无用处,也 没有警察或政府,街道被匪徒和暴力所统治。他,他的家庭,以及社区所采用的生存策略是:保持警惕,为了生存重新考虑哪些才是最重要的。虽然这是一篇很长的 文章,但考虑到文中这位生存下来的人所提供的大量宝贵知识,我还是强烈推荐本文。

- 阅读剩余部分 -

Automatic Snapshots for Google (gcloud) Compute Engine

Bash script for Automatic Snapshots and Cleanup on Google Compute Engine. Requires no user input!

Inspiration (and the installation instructions) taken from AWS script aws-ec2-ebs-automatic-snapshot-bash

How it works will:

  • Determine the Instance ID of the Google Compute Engine server on which the script runs
  • Get all the Disk IDs attached to that instance
  • Take a snapshot of each Disk
  • The script will then delete all associated snapshots taken by the script for the Instance that are older than 7 days (optional: default snapshot retention can be changed by using -d flag)


  • cURL must be installed
  • The VM must have the sufficient gcloud permissions, including "compute" set to "enabled":

  • The version of gcloud is up to date: gcloud components update


ssh on to the server you wish to have backed up

Install Script: Download the latest version of the snapshot script and make it executable:

cd ~
chmod +x
sudo mkdir -p /opt/google-compute-snapshot
sudo mv /opt/google-compute-snapshot/

To manually test the script:

sudo /opt/google-compute-snapshot/

Setup CRON: You should then setup a cron job in order to schedule a daily backup. Example cron for Debian based Linux:

0 5 * * * root /opt/google-compute-snapshot/ >> /var/log/cron/snapshot.log 2>&1

Please note: the above command sends the output to a log file: /var/log/cron/snapshot.log - instructions for creating & managing the log file are below.

Manage CRON Output: You should then create a directory for all cron outputs and add it to logrotate:

  • Create new directory:
sudo mkdir /var/log/cron 
  • Create empty file for snapshot log:
sudo touch /var/log/cron/snapshot.log
  • Change permissions on file:
sudo chgrp adm /var/log/cron/snapshot.log
sudo chmod 664 /var/log/cron/snapshot.log
  • Create new entry in logrotate so cron files don't get too big :
sudo nano /etc/logrotate.d/cron
  • Add the following text to the above file:
/var/log/cron/*.log {
    rotate 14
    create 664 root adm

Snapshot Retention

By default snapshots will be kept for 7 days, however they can be kept for longer / shorter, by using the the -d flag:

Usage: ./ [-d <days>]


   -d  Number of days to keep snapshots. Snapshots older than this number deleted.
       Default if not set: 7 [OPTIONAL]

要阻止 IP 直接访问 80 端口,请创建新的或添加到现有的服务器配置,如下所示:

server {
 listen 80 default_server;
 server_name _;
 return 404;

要阻止 IP 的直接访问 443 端口,请在其中一个服务器配置块中使用以下命令:

if ($host != "") {
 return 404;


server {
 listen 443 ssl;
 ssl_certificate /etc/nginx/ssl/;
 ssl_certificate_key /etc/nginx/ssl/;

 if ($host != "") {
  return 404;

这将阻止所有流量到 https://YOUR_IP_ADDRESS


本文翻译 NGINX – Disable direct access (via http and https) to a website using IP address

Q: 如何限制 php 访问其他目录

open_basedir 设置能将 PHP 所能打开的文件限制在指定的目录树,包括文件本身。

当一个脚本试图用例如 fopen() 或者 gzopen() 打开一个文件时,该文件的位置将被检查。当文件在指定的目录树之外时 PHP 将拒绝打开它。

; open_basedir, if set, limits all file operations to the defined
directory ; and below. This directive makes most sense if used in a
per-directory ; or per-virtualhost web server configuration file. ; ;open_basedir =

Q: 如何在 Nginx 对站点配置:

location ~ \.php$ {
  fastcgi_index  index.php;
  fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
  fastcgi_param  PHP_VALUE "open_basedir=/srv:/tmp";
  include        fastcgi_params;

March 13, 2018, Let’s Encrypt Wildcard certificate support is live.

How to use it? Follow me.

git clone
./certbot-auto certonly --manual -d * --agree-tos --manual-public-ip-logging-ok --preferred-challenges dns-01 --server