auto start fcitx in vncserver
- 安装必要软件
apt install fcitx fcitx-frontend-all fcitx-tools fcitx-config-gtk2 im-switch
- 设置.bashrc
$ vim ~/.bashrc # append
export XMODIFIERS=@im=fcitx
export XIM=fcitx
export XIM_PROGRAM=fcitx
export GTK_IM_MODULE=fcitx
export QT_IM_MODULE=fcitx
- 设置vnc
$ vim ~/.vnc/xstartup # append
startxfce4 &
fcitx &
boot with encrypted lvm root directory (crypt)
参考
- 初始化分区
cryptsetup --verbose --verify-passphrase luksFormat /dev/sda4
- 打开新加密的设备，命名为lvm_pv
cryptsetup luksOpen /dev/sda4 lvm_pv
- 确保设备存在
ls -l /dev/mapper | grep lvm_pv
- 执行pvcreate, vgcreate, lvcreate等命令设置
- cat /etc/crypttab
lvm_pv /dev/sda4 none luks
- update-initramfs -u -k all
- 修改密码
cryptsetup luksAddKey
- 移除密码
cryptsetup luksRemoveKey
- umount所有的文件系统
- 关闭该加密的设备
cryptsetup luksClose /dev/mapper/usb
vncserver中不能修改NetworkManager Applet中的设置
[问题描述]（https://bugs.launchpad.net/ubuntu/+source/policykit-1-gnome/+bug/1512002）
For some reason(s) it's considering us an "inactive user" (inactive means not in the active screen of the pc, either remote or in a screensaver etc) and thus we need authentication.
The necessary rights are defined in this file:
/usr/share/polkit-1/actions/org.freedesktop.accounts.policy
...
...
I think that if we change "
to "
we'll have a temporary workaround to the problem.
But the real issue is, should the system consider us "inactive" in the screen saver?
Should it consider us inactive in ltsp thin clients that are remote sessions?
Should it consider us inactive in ltsp fat clients where accountsservice doesn't have information about the remote user account? (similar with ldap)
If the answer to the above is yes, then maybe the workaround that I mentioned above should be committed to accountsservice?
git相关
递归stop track
It seems like you want the files ignored but they have already been commited.
".gitignore" has no effect on files that are already in the repo so they need to be removed with git rm --cached.
The --cached will prevent it from having any effect on your working copy and it will just mark as removed the next time you commit.
After the files are removed from the repo then the .gitignore will prevent them from being added again.
git rm -r --cached ~/.vim/*
MVC
MVC的优点：
- 最重要的是应该有多个视图对应一个模型的能力。
在目前用户需求的快速变化下，可能有多种方式访问应用的要求。
例如，订单模型可能有本系统的订单，也有网上订单，或者其他系统的订单，但对于订单的处理都是一样，也就是说订单的处理是一致的。按MVC设计模式，一个订单模型以及多个视图即可解决问题。这样减少了代码的复制，即减少了代码的维护量，一旦模型发生改变，也易于维护。
其次，由于模型返回的数据不带任何显示格式，因而这些模型也可直接应用于接口的使用。 - 由于一个应用被分离为三层，因此有时改变其中的一层就能满足应用的改变。一个应用的业务流程或者业务规则的改变只需改动MVC的模型层。
- 控制层的概念也很有效，由于它把不同的模型和不同的视图组合在一起完成不同的请求，因此，控制层可以说是包含了用户请求权限的概念。
- 它还有利于软件工程化管理。由于不同的层各司其职，每一层不同的应用具有某些相同的特征，有利于通过工程化、工具化产生管理程序代码。
MVC的不足：
- 增加了系统结构和实现的复杂性。对于简单的界面，严格遵循MVC，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。
- 视图与控制器间的过于紧密的连接。视图与控制器是相互分离，但对于确实联系紧密的部件，如果视图没有控制器的存在，那么其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。
- 视图对模型数据的低效率访问。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。
- 目前，一般高级的界面工具或构造器不支持MVC模式。改造这些工具以适应MVC需要和建立分离的部件的代价是很高的，从而造成使用MVC的困难。
书籍推荐
范畴学
链接器
定义（definition）是指建立某个名字与该名字的实现之间的关联，这里的“实现”可以是数据，也可以是代码：
变量的定义，使得编译器为这个变量分配一块内存空间，并且还可能为这块内存空间填上特定的值
函数的定义，使得编译器为这个函数产生一段代码
声明（declaration）是告诉 C 编译器，我们在程序的别处——很可能在别的 C 文件中——以某个名字定义了某些内容（注意：有些时候，定义也被认为是声明，即在定义的同时，也在此处进行了声明）。
对于变量而言，定义可以分为两种：
全局变量（global variables）和局部变量（local variables）。
以下是一个示例程序，也许是一种更简便的记忆方法：
/* 这是一个未初始化的全局变量的定义 */
int x_global_uninit;
/* 这是一个初始化的全局变量的定义 */
int x_global_init = 1;
/* 这是一个未初始化的全局变量的定义，尽管该变量只能在当前 C文件中访问 */
static int y_global_uninit;
/* 这是一个初始化的全局变量的定义，尽管该变量只能在当前 C文件中访问 */
static int y_global_init = 2;
/* 这是一个存在于程序别处的某个全局变量的声明 */
extern int z_global;
/* 这是一个存在于程序别处的某个函数的声明（如果你愿意，你可以在语句前加上 "extern"关键字，但没有这个必要） */
int fn_a( int x, int y);
/* 这是一个函数的定义，但由于这个函数前加了 static限定，因此它只能在当前 C文件内使用 */
static int fn_b(int x)
{
return x +1;
}
/* 这是一个函数的定义，函数参数可以认为是局部变量 */
int fn_c( int x_local)
{
/* 这是一个未初始化的局部变量的定义 */
int y_local_uninit ;
/* 这是一个初始化的局部变量的定义 */
int y_local_init = 3 ;
/* 以下代码通过局部变量、全局变量和函数的名字来使用它们 */
x_global_uninit = fn_a (x_local, x_global_init);
y_local_uninit = fn_a (x_local, y_local_init);
y_local_uninit += fn_b (z_global);
return (x_global_uninit + y_local_uninit);
}
/* 这是一个未初始化的全局变量的定义 */
int x_global_uninit;
/* 这是一个初始化的全局变量的定义 */
int x_global_init = 1;
/* 这是一个未初始化的全局变量的定义，尽管该变量只能在当前 C文件中访问 */
static int y_global_uninit;
/* 这是一个初始化的全局变量的定义，尽管该变量只能在当前 C文件中访问 */
static int y_global_init = 2;
/* 这是一个存在于程序别处的某个全局变量的声明 */
extern int z_global;
/* 这是一个存在于程序别处的某个函数的声明（如果你愿意，你可以在语句前加上 "extern"关键字，但没有这个必要） */
int fn_a( int x, int y);
/* 这是一个函数的定义，但由于这个函数前加了 static限定，因此它只能在当前 C文件内使用 */
static int fn_b(int x)
{
return x +1;
}
/* 这是一个函数的定义，函数参数可以认为是局部变量 */
int fn_c( int x_local)
{
/* 这是一个未初始化的局部变量的定义 */
int y_local_uninit ;
/* 这是一个初始化的局部变量的定义 */
int y_local_init = 3 ;
/* 以下代码通过局部变量、全局变量和函数的名字来使用它们 */
x_global_uninit = fn_a (x_local, x_global_init);
y_local_uninit = fn_a (x_local, y_local_init);
y_local_uninit += fn_b (z_global);
return (x_global_uninit + y_local_uninit);
}
无论一段代码在何处使用某个变量或者调用某个函数，编译器都只允许使用已经声明（declaration）过的变量和函数——
这样看来，声明其实就是程序员对编译器的承诺：向它确保这个变量或函数已经在程序中的别处定义过了。
链接器（linker）的作用则是兑现这一承诺，但反过来考虑，编译器又如何在产生目标文件的过程中兑现这些承诺呢？
大致说来，编译器会留个空白（blank），这个“空白”（我们也称之为“引用”（reference））拥有与之相关联的一个名字，但该名字对应的值还尚未可知。
剖析目标文件
现在深入细节研究一下之前介绍的理论在实际中都是怎么工作的。
这里我们需要用到一个很关键的工具，即命令：nm，这是一条UNIX平台上使用的命令，它可以提供目标文件的符号（symbols）信息。
在Windows平台上，与其大致等价的是带 /symbols 选项的 dumpbin 命令；当然，你也可以选择安装 Windows 版的 GNU binutils 工具包，其中包含了 nm.exe。
c_parts.o 中的符号如下：
Name Value Class Type Size Line Section
fn_a | | U | NOTYPE| | |*UND*
z_global | | U | NOTYPE| | |*UND*
fn_b |00000000| t | FUNC|00000009| |.text
x_global_init |00000000| D | OBJECT|00000004| |.data
y_global_uninit |00000000| b | OBJECT|00000004| |.bss
x_global_uninit |00000004| C | OBJECT|00000004| |*COM*
y_global_init |00000004| d | OBJECT|00000004| |.data
fn_c |00000009| T | FUNC|00000055| |.text
不同平台的输出内容可能会有些许不同（你可以用 man 命令来查看帮助页面，从中获取某个特定版本更多的相关信息），但它们都会提供这两个关键信息：每个符号的类型，以及该符号的大小（如果该符号是有效的）。符号的类型包括以下几种（译者注[1]）：