Linux相关整理

2018-07-23  本文已影响0人  warmyouth

auto start fcitx in vncserver

apt install fcitx fcitx-frontend-all fcitx-tools fcitx-config-gtk2 im-switch
$ vim ~/.bashrc  # append
export XMODIFIERS=@im=fcitx
export XIM=fcitx
export XIM_PROGRAM=fcitx
export GTK_IM_MODULE=fcitx
export QT_IM_MODULE=fcitx
$ vim ~/.vnc/xstartup  # append
startxfce4 &
fcitx &

boot with encrypted lvm root directory (crypt)

参考

cryptsetup --verbose --verify-passphrase luksFormat /dev/sda4
cryptsetup luksOpen /dev/sda4 lvm_pv
ls -l /dev/mapper | grep lvm_pv
lvm_pv /dev/sda4 none luks
cryptsetup luksAddKey <device>
cryptsetup luksRemoveKey <device>
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

<action id="org.freedesktop.accounts.change-own-user-data">
...
<defaults>
<allow_any>auth_self</allow_any>
<allow_inactive>auth_self</allow_inactive>
<allow_active>yes</allow_active>
</defaults>
...

I think that if we change "<allow_inactive>auth_self</allow_inactive>"
to "<allow_inactive>yes</allow_inactive>",
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的不足:

书籍推荐

范畴学

链接器

定义(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]):

上一篇 下一篇

猜你喜欢

热点阅读