做事四部曲 -- 有做、做完、做對、做好

仔細看工作有四個層次，有做、做完、做對、做好，就不難找到問題所在

• 「有做」、「做完」是具象而明確的，可以用過程來檢驗
• 「做對」、「做好」則是質量的層次，不容易用過程來檢驗

一個工作開始時，由於不熟悉，可以要求先做，做完就好。一旦過了這個時期，

就要要求「做對」、「做好」。

套句廣告詞「先求不傷身體，再講求藥效。」

Ubuntu MTRG 設定

首先要安裝snmpd 及 MRTG：
apt-get install snmpd mrtg

安裝mrtg 時會進入一個畫面詢問你的mrtg.cfg檔要不要只讓mrtg使用者讀取
選擇Yes


設定SNMP：
vi /etc/snmp/snmpd.conf
修改下列
#com2sec paranoid default public
com2sec readonly default public
重新啟動
/etc/init.d/snmpd restart

然後利用cfgmaker自動產生設定：
cfgmaker public@localhost > /etc/mrtg.cfg

執行mrtg：
env LANG=C mrtg /etc/mrtg.cfg
多執行幾次，直到沒有警告訊息。

設定 Crontab
*/5 * * * * env LANG=C /usr/bin/mrtg /etc/mrtg.cfg

將 KDE 的目錄改成英文

將 KDE 在 home dir 中建的目錄改成英文

修改 ~/.config/user-dirs.dirs

XDG_DESKTOP_DIR="$HOME/Desktop"
XDG_DOWNLOAD_DIR="$HOME/Desktop"
XDG_TEMPLATES_DIR="$HOME/Template"
XDG_PUBLICSHARE_DIR="$HOME/Public"
XDG_DOCUMENTS_DIR="$HOME/Documents"
XDG_MUSIC_DIR="$HOME/Musics"
XDG_PICTURES_DIR="$HOME/Pictures"
XDG_VIDEOS_DIR="$HOME/Videos"

然後手動將相對應的目錄改成英文

Ubuntu 9.04 中文輸入(Scim)設定

在 Ubuntu 9.04 上設定 scim

• sudo aptitude install language-pack-zh
• sudo aptitude install language-support-zh

設定 locale

• export LANG="zh_TW.UTF-8"
• export LANGUAGE="zh_TW:zh"
• export GTK_IM_MODULE="scim-bridge"
• export QT_IM_MODULE="xim"
• export XMODIFIERS="@im=SCIM"

Ubuntu 9.04 telnet server 設定

安裝 telnet service

sudo apt-get install xinetd telnetd

安裝完成，設定一下吧！

sudo vi /etc/inetd.conf並加入以下一行

telnet stream tcp nowait telnetd /usr/sbin/tcpd /usr/sbin/in.telnetd

接下來新增 /etc/xinetd.d/telnet 這個檔案，讓telnetd自動開啟service

sudo vi /etc/xinetd.d/telnet

service telnet
{
     disable = no
     socket_type = stream
     protocol = tcp
     wait = no
     user = telnetd
     server = /usr/sbin/in.telnetd
}

LINUX System Programming -- File I/O

File I/O

---

This chapter introduces files, the most important abstraction in the Unix environment, and file I/O, the basis of the Linux programming mode. This chapter covers reading from and writing to files, along with other basic file I/O operations. The chapter culminates with a discussion on how the Linux kernel implements and manages files.

Opening Files

Reading via read( )

---

 #include <unistd.h>
 ssize_t read (int fd, void *buf, size_t len);

Return Values:

---

• The call returns a value equal to len. All len read bytes are stored in buf. The results are as intended.
• The call returns a value less than len, but greater than zero. The read bytes are stored in buf.
• The call returns 0. This indicates EOF. There is nothing to read.
• The call blocks because no data is currently available. This won’t happen in non-blocking mode.
• The call returns -1, and errno is set to EINTR. This indicates that a signal was received before any bytes were read. The call can be reissued.
• The call returns -1, and errno is set to EAGAIN. This indicates that the read would block because no data is currently available, and that the request should be reissued later. This happens only in nonblocking mode.
• The call returns -1, and errno is set to a value other than EINTR or EAGAIN. This indicates a more serious error.
  

---

ssize_t ret;
while (len != 0 && (ret = read (fd, buf, len)) != 0) {
   if (ret == -1) {         
          if (errno == EINTR)                 
                  continue;         
          perror ("read");         
          break;
   }
   len -= ret;
   buf += ret;
}

---

Writing with write( )

Synchronized I/O

Direct I/O

Closing Files

Seeking with lseek( )

Positional Reads and Writes

Truncating Files

Multiplexed I/O:

---

Multiplexed I/O allows an application to concurrently block on multiple file descriptors, and receive notification when any one of them becomes ready to read or write without blocking. Multiplexed I/O thus becomes the pivot point for the application, designed similarly to the following:

1. Multiplexed I/O: Tell me when any of these file descriptors are ready for I/O.
2. Sleep until one or more file descriptors are ready.
3. Woken up: What is ready?
4. Handle all file descriptors ready for I/O, without blocking.
5. Go back to step 1, and start over.

Select

---

#include <sys/time.h>
#include <sys/types.h>
#include <unistd.h>

int select (int n,
           fd_set *readfds,
           fd_set *writefds,
           fd_set *exceptfds,
           struct timeval *timeout);

FD_CLR(int fd, fd_set *set);
FD_ISSET(int fd, fd_set *set);
FD_SET(int fd, fd_set *set);
FD_ZERO(fd_set *set);

A call to select( ) will block until the given file descriptors are ready to perform I/O,or until an optionally specified timeout has elapsed.
The timeout parameter is a pointer to a timeval structure, which is defined as follows:

#include <sys/time.h>
struct timeval {
   long tv_sec;         /* seconds */
   long tv_usec;        /* microseconds */
};

FD_ISSET tests whether a file descriptor is part of a given set.FD_ISSET is used after a call from select( ) returns to test whether a given file descriptor is ready for action:

if (FD_ISSET(fd, &readfds))
          /* 'fd' is readable without blocking! */

pselect( )

---

#define _XOPEN_SOURCE 600

#include <sys/select.h>

int pselect (int n,
            fd_set *readfds,
            fd_set *writefds,
            fd_set *exceptfds,
            const struct timespec *timeout,
            const sigset_t *sigmask);

FD_CLR(int fd, fd_set *set);
FD_ISSET(int fd, fd_set *set);
FD_SET(int fd, fd_set *set);
FD_ZERO(fd_set *set);

There are three differences between pselect( ) and select( ):

1. pselect( ) uses the timespec structure, not the timeval structure, for its timeout parameter. The timespec structure uses seconds and nanoseconds, not seconds and microseconds, providing theoretically superior timeout resolution. In practice, however, neither call reliably provides even microsecond resolution.
2. A call to pselect( ) does not modify the timeout parameter. Consequently, this parameter does not need to be reinitialized on subsequent invocations.
3. The select( ) system call does not have the sigmask parameter. With respect to signals, when this parameter is set to NULL, pselect( ) behaves like select( ).

poll( )

---

The poll( ) system call is System V’s multiplexed I/O solution. It solves several defi-ciencies in select( ), although select( ) is still often used (again, most likely out of habit, or in the name of portability):

#include <sys/poll.h>
int poll (struct pollfd *fds, unsigned int nfds, int timeout);

Unlike select( ), with its inefficient three bitmask-based sets of file descriptors, poll( ) employs a single array of nfds pollfd structures, pointed to by fds. The structure is defined as follows:

#include <sys/poll.h>

struct pollfd {
   int fd;           /* file descriptor */
   short events;     /* requested events to watch */
   short revents;    /* returned events witnessed */
};

POLLIN | POLLPRI is equivalent to select( )’s read event, and POLLOUT | POLLWRBAND is equivalent to select( )’s write event. POLLIN is equivalent to POLLRDNORM | POLLRDBAND, and POLLOUT is equivalent to POLLWRNORM.

poll( ) Versus select( )

---

Although they perform the same basic job, the poll( ) system call is superior to
select( ) for a handful of reasons:

• poll( ) does not require that the user calculate and pass in as a parameter the value of the highest-numbered file descriptor plus one.
• poll( ) is more efficient for large-valued file descriptors. Imagine watching a single file descriptor with the value 900 via select( )—the kernel would have to check each bit of each passed-in set, up to the 900th bit.
• select( )’s file descriptor sets are statically sized, introducing a tradeoff: they are small, limiting the maximum file descriptor that select( ) can watch, or they are inefficient. Operations on large bitmasks are not efficient, especially if it is not known whether they are sparsely populated.* With poll( ), one can create an array of exactly the right size. Only watching one item? Just pass in a single structure.
• With select( ), the file descriptor sets are reconstructed on return, so each sub-sequent call must reinitialize them. The poll( ) system call separates the input (events field) from the output (revents field), allowing the array to be reused without change.
• The timeout parameter to select( ) is undefined on return. Portable code needs to reinitialize it. This is not an issue with pselect( ), however.

The select( ) system call does have a few things going for it, though:

• select( ) is more portable, as some Unix systems do not support poll( ).
• select( ) provides better timeout resolution: down to the microsecond. Both ppoll( ) and pselect( ) theoretically provide nanosecond resolution, but in practice, none of these calls reliably provides even microsecond resolution.
  

LINUX System Programming -- Introduction and Essential Concepts

System Call

---

System programming starts with system calls. System calls (often shorted to syscalls).

• to execute and with what parameters via machine registers.
• As a system programmer, you usually do not need any knowledge of how the kernel handles system call invocation. That knowledge is encoded into the standard calling conventions for the architecture, and handled automatically by the compiler and the C library.

The C Library

---

The GNUC library provides more than its name suggests. In addition to implementing the standard C library, glibc provides wrappers for system calls, threading support, and basic application facilities.

The C Compiler

---

APIs and ABIs --Both define and describe the interfaces between different pieces of computer software.

• APIs

• Application programming interface
  
• An API defines the interfaces by which one piece of software communicates with another at the source level.
  
• A real-world example is the API defined by the C standard and implemented by the standard C library.
  

• ABIs
• Whereas an API defines a source interface, an ABI defines the low-level binary
  interface between two or more pieces of software on a particular architecture.
  
• An ABI ensures binary compatibility, guaranteeing that a piece of object code will function on any system with the same ABI, without requiring recompilation.
  
• ABIs are concerned with issues such as calling conventions, byte ordering, register use, system call invocation, linking, library behavior, and the binary object format.
  
• The ABI is enforced by the toolchain—the compiler, the linker, and so on
  

Standards

---

• POSIX
  
• In the mid-1980s, the Institute of Electrical and Electronics Engineers (IEEE) spearheaded an effort to standardize system-level interfaces on Unix systems. Richard Stallman, founder of the Free Software movement, suggested the standard be named POSIX (pronounced pahz-icks), which now stands for Portable Operating System Interface.
  

• C Language Standards
  
• Dennis Ritchie and Brian Kernighan’s famed book, The C Programming Language
  
• In 1990, the International Organization for Standardization (ISO) ratified ISO C90
  
• 1995 -- ISO C95
  
• This was followed in 1999 with a large update to the language, ISO C99, that introduced many new features, including inline functions, new data types, variable-length arrays, C++-style comments, and new library functions.
  

Linux and the Standards

---

Concepts of Linux Programming

---

Files and the Filesystem

• Regular files
  
• A regular file contains bytes of data, organized into a linear array called a byte stream.
  
• Any of the bytes within a file may be read from or written to. These operations start at a specific byte, which is one’s conceptual “location” within the file. This location is called the file position or file offset.
  
• Writing a byte to a file position beyond the end of the file will cause the intervening bytes to be padded with zeros.
  
• it is not possible to write bytes to a position before the beginning of a file.
  
• Writing a byte to the middle of a file overwrites the byte previously located at that offset. Thus, it is not possible to expand a file by writing into the middle of it.
  
• The size of a file is measured in bytes, and is called its length.
  
• a file is referenced by an inode (originally information node), which is assigned a unique numerical value. This value is called the inode number, often abbreviated as i-number or ino.
  
• files are always opened from user space by a name, not an inode number.
  


• Directories and links
  
• A directory acts as a mapping of human-readable names to inode numbers. A name and inode pair is called a link.
  
• Initially, there is only one directory on the disk, the root directory. This directory is usually denoted by the path /.
  
• A pathname that starts at the root directory is said to be fully qualified, and is called an absolute pathname.
  
• Some pathnames are not fully qualified; instead, they are provided relative to some other directory (for example, todo/plunder). These paths are called relative pathnames. When provided with a relative pathname, the kernel begins the pathname resolution in the current working directory.
  
• Hard links
  
• When multiple links map different names to the same inode, we call them hard links.
  
• Hard links allow for complex filesystem structures with multiple pathnames pointing to the same data.
  
• Deleting a file involves unlinking it from the directory structure, which is done simply by removing its name and inode pair from a directory.
  
• When a pathname is unlinked, the link count is decremented by one; only when it reaches zero are the inode and its associated data actually removed from the filesystem.
  
• Symbolic links (symlinks)
  
• Hard links cannot span filesystems because an inode number is meaningless
  outside of the inode’s own filesystem. To allow links that can span filesystems, and that are a bit simpler and less transparent, Unix systems also implement symbolic links (often shortened to symlinks).
  
• A symbolic link that points to a nonexistent file is called a broken link.
  
• Special files
  
• Special files are kernel objects that are represented as files.
  
• Linux supports four: block device files, character device files, named pipes, and Unix domain sockets.
  
• Special files are a way to let certain abstractions fit into the filesystem, partaking in the everything-is-a-file paradigm. Linux provides a system call to create a special file.
  
• Device files may be opened, read from, and written to, allowing user space to access and manipulate devices (both physical and virtual) on the system.
  
• Unix devices are generally broken into two groups: character devices and block devices.
  
• A character device is accessed as a linear queue of bytes. The device driver places bytes onto the queue, one by one, and user space reads the bytes in the order that they were placed on the queue.
  
• A block device, in contrast, is accessed as an array of bytes. The device driver maps the bytes over a seekable device, and user space is free to access any
  valid bytes in the array, in any order
  
• Named pipes (often called FIFOs, short for “first in, first out”) are an interprocess
  communication (IPC) mechanism that provides a communication channel over a file descriptor, accessed via a special file.
  
• Sockets are an advanced form of IPC that allow for communication between two different processes, not only on the same machine, but on two different machines. Unix domain sockets use a special file residing on a filesystem, often simply called a socket file.
  
• Filesystems and namespaces
  
• Linux, like all Unix systems, provides a global and unified namespace of files and directories.
  
• A filesystem is a collection of files and directories in a formal and valid hierarchy.
  
• Filesystems usually exist physically (i.e., are stored on disk), although Linux also supports virtual filesystems that exist only in memory, and network filesystems that exist on machines across the network.
  
• media-specific filesystems (for example, ISO9660), network filesystems (NFS), native filesystems (ext3), filesystems from other Unix systems (XFS), and even
  filesystems from non-Unix systems (FAT).
  
• The smallest addressable unit on a block device is the sector. A block device cannot transfer or access a unit of data smaller than a sector
  
• The smallest logically addressable unit on a filesystem is the block. The
  block is an abstraction of the filesystem
  

Processes

---

• Processes are object code in execution: active, alive, running programs. But they’re more than just object code—processes consist of data, resources, state, and a virtualized computer.
  
• Processes begin life as executable object code, which is machine-runnable code in an executable format that the kernel understands (the format most common in Linux is ELF).
  
• The most important and common sections are the text section, the data
  section, and the bss section.
  
• Processes typically request and manipulate resources only through system calls.
  
• A process’ resources, along with data and statistics related to the process, are stored inside the kernel in the process’ process descriptor.
  
• Threads
  
• Each process consists of one or more threads of execution (usually just called threads).
  
• A thread is the unit of activity within a process, the abstraction responsible for executing code, and maintaining the process’ running state.
  
• Most processes consist of only a single thread; they are called single-threaded.
  Processes that contain multiple threads are said to be multithreaded.
  
• A thread consists of a stack (which stores its local variables, just as the process stack does on nonthreaded systems), processor state, and a current location in the object code (usually stored in the processor’s instruction pointer). The majority of the remaining parts of a process are shared among all threads.
  
• Internally, the Linux kernel implements a unique view of threads: they are simply normal processes that happen to share some resources (most notably, an address space). In user space, Linux implements threads in accordance with POSIX 1003.1c (known as pthreads). The name of the current Linux thread implementation, which is part of glibc, is the Native POSIX Threading Library (NPTL).
  
• Process hierarchy
  
• Each process is identified by a unique positive integer called the process ID (pid). The pid of the first process is 1, init process.
  
• New processes are created via the fork( ) system call. This system call creates a duplicate of the calling process. The original process is called the parent; the new process is called the child.
  
• If a parent process terminates before its child, the kernel will reparent the child to
  the init process.
  
• A process that has terminated, but not yet been waited upon, is
  called a zombie.
  
• Users and Groups
  
• Authorization in Linux is provided by users and groups. Each user is associated with a unique positive integer called the user ID (uid).
  
• Each process is in turn associated with exactly one uid, which identifies the user running the process, and is called the process’ real uid.
  
• In addition to the real uid, each process also has an effective uid, a saved uid,
  and a filesystem uid.
  
• Each user may belong to one or more groups, including a primary or login group, listed in /etc/passwd, and possibly a number of supplemental groups, listed in /etc/group.
  
• Each process is therefore also associated with a corresponding group ID (gid), and has a real gid, an effective gid, a saved gid, and a filesystem gid.
  
• Permissions
  
• Table 1-1. Permission bits and their values
  
• Signals
  
• Signals are a mechanism for one-way asynchronous notifications. A signal may be sent from the kernel to a process, from a process to another process, or from a process to itself.
  
• Handled signals cause the execution of a user-supplied signal handler function. The program jumps to this function as soon as the signal is received, and (when the signal handler returns) the control of the program resumes at the previously interrupted instruction.
  
• Interprocess Communication
  
• Allowing processes to exchange information and notify each other of events is one of an operating system’s most important jobs.
  
• IPC mechanisms supported by Linux include pipes, named pipes, semaphores, message queues, shared memory, and futexes (short for "fast userspace mutex", Futex are Tricky).
  

Headers

---

Linux system programming revolves around a handful of headers. Both the kernel itself and glibc provide the headers used in system-level programming. These headers include the standard C fare (for example, ), and the usual Unix offerings (say, ).

Error Handling

---

Table 1-2. Errors and their descriptions

教練--第一章--價值型領導---以身作則創造共同價值

價值型領導---以身作則創造共同價值

• 凝聚共同價值觀
• 管理者要建立團隊就要先塑造自已帶領團隊的核心價值觀，要認清什麼是團隊不能隨意更改或打折的信念。
• 誠信是必要的品格
• 不論從被領導的角度，或是領導者的角度，「誠信」皆是身為一個管理者的重要特質。
• 有人說：「做自已所說的，做自已該做的，就是誠信的基本表現。」
• 「誠信是管理者不可棄守的底線。」不論你面對何種壓力，因為這是你在團隊中賴以維繫成員的基本力量。
  
• 信賴是教練的根基
• 「信賴」是凝聚團隊共同價值觀與原景的主要成份，一個團隊成員若能相互信任，就傳表一個團隊的力量可以整合。反之成員間必心存戒心，終日擔心決策或決定是否對其不利？用心於負面思考而忘了團隊存在的意義，當然團隊的動力就被磨掉了
• 對管理者而言，獲得成員信任是在展現管理者的能力和操守--反之，則管理者的能力就要被質疑了
• 唯有信賴的關係存在於團隊中，才能讓團隊產生凝聚力，才能讓每卷成員皆有安全感及被尊重感。成員感受到這股信賴的力量，就會勇於表現自已的能力，不用擔心行為會受到誤解；設於對團隊做出更大的承諾與貢獻，就會全力以赴，達成目標
• 學者說； 「Trust is social capital.」對團隊成員亦是如此。一個團隊成員信賴程度的高低，維繫於團隊成員的互動良寙以及管理者的用心
  
• 價值觀的分享與傳承
• 團隊中的經驗是一切知識的基礎，每一個經驗皆是耗費時間、精力成本和血汗所換取而來的寶貴結果
• 管理者要啟動團隊中的經驗分享動力，以說故事的方式是最吸引人且最直接有效的做法
  
• 教練風範--保持謙沖的心
• 在團隊互動中管理者愈能謙虛的與團隊溝通共同學習，則團隊成員必然願真心誠意去表達自已的意見，貢獻自已的力量來達成團隊的目標
• 一位保有謙沖的心的管理者，較能看清楚自已的局限性，認知自已有能力不足之處，也能勇於面對自已犯錯的地方，虛心的改過求善
  
• 虛已下問
• 團隊中蘊藏著許多的智及潛能，如何發掘與用一直是管理者努力追求的方向
• 一位優秀的管理者知道在帶領團隊時，要發掘團隊的智慧，首先要做的就是謙虛用心的向團隊學習和請益，從傾聽團隊成員的聲音開始，才能有效發現問題、激發團隊動力及擬訂出有效的對策
• 任何一位管理者其能力再強終有其限制，不可能只憑一已之力就能解決在組識內所有的問題，因此要有效領導團隊就必須能傾聽成只聲音、向團隊學習，激發團隊力量來解決所面對的問題
  
• 勇於認錯
• 勇於認錯並加以改正是管理者待人處事的重要原則
• 管理者要防止自已犯錯而影響團隊最佳方法，就是培養自我檢討的動力，並勇於認錯
• 團隊成員眼員的眼精是雪亮的，對管理者的行為皆看在眼裡，當管理者犯錯時所有成員的心裡是很明白的，所以真正的問題不在犯錯本身，而是看管理者願不願意認錯及改正
• 一位夫去誠信的管理者是很難有效帶領團隊的，因為失去誠信猶如失去權勢，管理者必須謹慎看待自已的言行
  
• 樹立典範
• 所謂「上行下效」，管理者的行事風範是團隊成員學習模仿的對象，他的言行是否一致也是成員隨時檢驗和評斷的對象。
• 要成為一個好的管理者絕非偶然，它需要在行動中樹立榜樣，成為團隊的標竿以及學習對象，激發出成員主動行事的精神
• 在組織中只說不做的主管最為人所垢病，管理者一定要用心和成員溝通，將自已的價值觀傳達給成員，同時要力行自已所說的，不能以身作則是絕對令人心服的。
• 讓團隊認同管理者的理念言行，並且願意遵行是最佳的領導
• 「領導統御就是樹立榜樣，言行一致，才能據以說服別人。」絕對不要忽視成員的能力，在團隊鄉唯有自我要求以身做則，藉由言行一致樹立團隊典範，才能成為優質的管理者
  
• 以身作則
• 有效帶領團隊的核心就是以身作則，除此之外沒有更好的做法
  

每天早上只要30分鐘--第七章--自我啟發的陷阱

自我啟發的陷阱

• 只知道學習方法的人，需要的是實際的行動
• 錢要花在擠出時間的作業上，而不花在教材、服務上
• 如果自已沒有辦法提供對方好處，建立人脈就完全無濟於事
• 如果有多餘的時間建立人脈，不如努力學習，培植實力，累積實績要來的實際些
• 不學習、不努力的人光靠自我形象，自我暗示是沒有用的
  

每天早上只要30分鐘--第六章--掌握運勢的學習法及想法

掌握運勢的學習法及想法

• 運氣只出現在準備好的人面前
• 在人生的過程中想要掌握運勢，就必須持續的學習
• 你的思考方式的成果就是現在你自已本身
• 不想正視現實的人總是戴著有色眼鏡，以扭曲的角度看現實
• 使用特殊解答(一夕成功的方法)時，成功機會幾乎是零
• 只要烙印在潛意識中，你的習慣就會自動改變
• 即使閱讀同一本書，看一遍跟反覆看好幾次所得到的成果是截然不同的
• 「知道」和「學會」的差異有如天壤之別
• 只要把具生產性的行動烙印在潛意識中，自動就會從事具生產性的活動
• 沒有反覆學習和練習，就成不了該領域的達人
• 如果學習或練習的量段別人的三~五倍多，就無法顯出差距
• 如果要提昇某個領域的知識和技能，就在該領域投注時間、勞力、金錢
• 只要慢慢嶄露頭角，好工作終究會找上門
  

每天早上只要30分鐘--第五章--在不同的人生階段安排學習時間的方法

在不同的人生階段安排學習時間的方法

• 按照人生的不同階段改變學習方法的形態
• 單生時代擁有可以自由學習的環境，應該盡情的學習
• 單身時代自我學習的多少，對往後人生有重大改變
• 我們因為過去的累積而得到現在的收入
• 不想在十年二十年後過貧困的生活，唯有趁現在自我投資
• 新婚時期將傍晚時段定為夫妻時間，避免學習活動，相對的早上提早床學習
• 夜晚學習幾乎不可能，因此宜持續進行早上的學習活動
• 有了小孩以後，更需要妥善安排時間
• 和家人共處的時間，儘量不要從事學習活動
  

每天早上只要30分鐘--第四章--持續早上學習的機制

持續早上學習的機制

• 找到一個讓自已非得早上學習不可的強烈理由、動機
• 告訴自已，這是為了對自已而言很重要的人所作的努力
• 只要是能為自已點火的動機，什麼動機都可以
• 不要怕失敗，反覆嘗試錯誤，慢慢養成早起學習的習慣
• 沒有是從一開始就平平順順地獲得成功的
• 一般世俗的現象是，除非超過臨界點，否則通常不會發生任何變化
• 只要作法沒有錯，持續十五個月以上，就一定會發生某種效應
• 早上無法早起學習的原因是因為晚上太晚就寢
  

每天早上只要30分鐘--第三章--成功的人都採用這種學習方法

成功的人都採用這種學習方法

• 前一天晚上就要決定第二天早上的學習內容
• 不要摻雜休習時間，藉改變學習的內容來轉換心情，持續進行學習、工作
• 開始進行早上的學習作業時，最重要的事情就是養成早上學習的習慣
• 以自已的工作表現被譽為前 10% 的領域為目標
• 為了學習某種特定技能而從事的學習活動，要集中在一個領域
• 不要勉強行事，從早上30 分鐘的學習開始嘗試
• 如果要取得某種資格，就擬定簡單學習計畫
• 記憶是透過睡眠以情報的模式啟印在腦中，所以背誦的學習適合夜晚為之

每天早上只要30分鐘--第二章--絕對會製造效果的早上學習建議事項

絕對會製造效果的早上學習建議事項

• 夜晚學習通常是在一天工作之後，精神體力不好，學習成果也不好
• 持續學習要有好的成果，睡眠是很重要的
• 夜晚有很多不具生產力活動的誘惑--如電視
• 早上的時間過得比較慢
• 早上的一個小時足以抵晚上二個小時
• 業績好的社長的共通點就是上班時間早
• 不管工作、學習或運動，輸入量多的人占優勢
• 早上的時間受限制，因此會花心思好讓學習活動在限制時間內變得有效率
• 早上學習的些微差異長期累積下來，就會顯現出非常大的效率和學習量的差異
  

每天早上只要30分鐘--第一章--持續做理所當然的事情的人穩操勝券

持續做理所當然的事情的人穩操勝券

• 只要腳踏實地累積基本練習，你磺可以成為該領域的達人
• 在某個領域獲得成功的人並沒有每次都做新的事情或不同的事情
• 只要持續做理所當然的事情，就可以在該領域獲得成功，進入前10%
• 時間是影響學習成果的最重要因素
• 一流選手華麗舞台背後都是數倍於台前的訓練和努力
• 因為實踐甲別人無法實踐的事情，所以有其價值存在
• 你只要投資少許的時間、勞力和金錢，持續每天孜孜不倦的學習就可以了
• 如果你想選擇確實地獲得成功的方法，那就必須選擇一般的解答
  

人性的弱點--第二篇--使人喜歡你的六種方法

使人喜歡你的六種方法

• 真誠的對別人發生興趣，談論別人感興趣的話題
• 微笑
• 記住每一個和你接觸的人的名字
• 做一個善於靜聽的人，並鼓勵他人多談談他們自已
• 就別人的興趣談論
• 讓人感覺到他的重要--必須真誠的這樣做
  

人性的弱點--第一篇--待人的基本技巧

• 不要批評、責怪或抱怨。
• 不要評議人，免得為人所評議
• 批評就像我們養的鴿子一樣，永遠會飛回家的
• 尖銳的批評、斥責『永遠不會有效果的』
• 任何一個愚蠢的人都會批評人、斥責人和抱怨人；同人也是絕大部份愚蠢的人才會這樣做
• 上帝在末日之前，還不打算審判任何人
  
• 與人相處的大絕竅
• 天底下只有一個方法可以使任何一個人去做任何一件事，那就是『使人願意去做那件事』
• 人類天性中最深切的衝動--『成為重要人物的慾望』
• 用人想成為重要人物的慾望，讓他人做自已想要他做的事
  
• 左右逢的方法
  
• 世界上唯一可以影響他人的方法，就是談論他所要的，而且還要告訴他，如何才能得到它
• 要別人做任何事之前，先引起別人的渴望
  

自動備份 Script

網路上找來的，改了一點
==============================================
#!/bin/sh

backup_dir="/home/backup"
source_dir="/source"

MKDIR="$(which mkdir)"
TAR="$(which tar)"
MV="$(which mv)"
TODAY=`/bin/date +%Y%m%d`

test ! -d "$backup_dir/0/" && $MKDIR "$backup_dir/0/"

# tar zcv all file
$TAR zcPf "$backup_dir/0/source_$TODAY.tgz" $source_dir

# remove the oldest backup
test -d "$backup_dir/8/" && rm -rf "$backup_dir/8"

# rotate
for int in 7 6 5 4 3 2 1 0
do
if(test -d "$backup_dir"/"$int")
then
next_int=`expr $int + 1`
$MV "$backup_dir"/"$int" "$backup_dir"/"$next_int"
fi
done

exit 0;

無為而治－－企業成功之道

企業要管理的對象是制度還是員工？這個問題見仁見智。但制度明確，員工有依循的標準，管理者可以較容易管理企業。緊迫盯人的管理方式，實不如制度明確『無為』的管理方式。

改變！？不改終生遺憾，變錯遺憾終生！？

馬英九用換人換黨(change)，當上總統，台灣人相信，改變會帶來轉機。
歐巴馬用改變(change)選上了美國總統，美國人相信，改變會帶來轉機。

而我們呢？想用工作改變來解決屬下的衝突問題，我們相信？！我想會不會搞錯了方向？套句話說，『笨蛋，問題在上頭，不在下頭！』只是不知沒有人聽的進去！

改變！？不改終生遺憾，變錯遺憾終生！？ 希望不要一語成讖！

這是你的船

• 密而不宣的事，只會增加人們的猜忌
  

工作要用對方法

• 在可能的限度內，儘早做決定。延後做決定不一定會有比較好的結果。有時反而會造成問題的擴散
  
• 從最困難的工作下手
  
• 養成站在他人的立場想事情，會有意想不到的結果
  
• 好的開始就是成功一半。萬事起頭難，看似困難的工作，只要動手進行，工作等於完成一半
• 暫時擱置問題，不會有好的判斷
  
• 建立工作風格－－展現出自已是有工作能力的
• 別為了自我的方便，浪費他人的時間
• 收起先入為主的觀念和假設，最初還是聽對方好好說吧！
• 事情不會做不完，只要提早動手
  

寫給經理的教科書

這是一本寫給經理(日本:部長)的書

• 成為經理會帶來什麼改變
• 經理的立場微妙，公司內負有預算管理責任的最基層。擁有考核下屬績效的最低職位
• 能否升任經理，乃是職涯發展的重大關鍵

• 經理工作的首要任務－－員工工作情緒管理
• 熟悉每位員下屬
• 透過情緒管理提高下屬工作土氣

• 經理負責溝通公司上下的價值觀