Group items tagged

A Pod models an application-specific “logical host”

being executed on the same physical or virtual machine would mean being executed on the same logical host.

The shared context of a Pod is a set of Linux namespaces, cgroups, and potentially other facets of isolation

Containers in different Pods have distinct IP addresses and can not communicate by IPC without special configuration. These containers usually communicate with each other via Pod IP addresses.

a Pod is modelled as a group of Docker containers with shared namespaces and shared filesystem volumes

Pods are considered to be relatively ephemeral (rather than durable) entities.

Pods are created, assigned a unique ID (UID), and scheduled to nodes where they remain until termination (according to restart policy) or deletion.

it can be replaced by an identical Pod

When something is said to have the same lifetime as a Pod, such as a volume, that means that it exists as long as that Pod (with that UID) exists.

uses a persistent volume for shared storage between the containers

Pods serve as unit of deployment, horizontal scaling, and replication

flat shared networking space

Containers within the Pod see the system hostname as being the same as the configured name for the Pod.

Volumes enable data to survive container restarts and to be shared among the applications within the Pod.

Individual Pods are not intended to run multiple instances of the same application

The individual containers may be versioned, rebuilt and redeployed independently.

Controllers like StatefulSet can also provide support to stateful Pods.

When a user requests deletion of a Pod, the system records the intended grace period before the Pod is allowed to be forcefully killed, and a TERM signal is sent to the main process in each container.

Once the grace period has expired, the KILL signal is sent to those processes, and the Pod is then deleted from the API server.

grace period

Pod is removed from endpoints list for service, and are no longer considered part of the set of running Pods for replication controllers.

When the grace period expires, any processes still running in the Pod are killed with SIGKILL.

By default, all deletes are graceful within 30 seconds.

You must specify an additional flag --force along with --grace-period=0 in order to perform force deletions.

Force deletion of a Pod is defined as deletion of a Pod from the cluster state and etcd immediately.

Processes within the container get almost the same privileges that are available to processes outside a container.

add the DNS service principal and acquire the keytab

All machines belonging to Kerberos realm EXAMPLE.COM are allowed to update own A record.

grant EXAMPLE.COM krb5-self * A;

Allow Kerberos principal SERVICE/ipaserver.example.com@EXAMPLE.COM to do any updates in whole zone.

Machine is allowed to update own PTR record in reverse zone.

with kinit. (This step is not required if the client was enrolled by ipa-client-install script or host keytab is already in place for other reasons.)

the "server dns.example.com" command tells nsupdate to update the specified DNS server

Auto DevOps works with any Kubernetes cluster;

using the Docker or Kubernetes executor, with privileged mode enabled.

Base domain (needed for Auto Review Apps and Auto Deploy)

Kubernetes (needed for Auto Review Apps, Auto Deploy, and Auto Monitoring)

Prometheus (needed for Auto Monitoring)

scrape your Kubernetes cluster.

project level as a variable: KUBE_INGRESS_BASE_DOMAIN

A wildcard DNS A record matching the base domain(s) is required

Once set up, all requests will hit the load balancer, which in turn will route them to the Kubernetes pods that run your application(s).

review/ (every environment starting with review/)

staging

production

need to define a separate KUBE_INGRESS_BASE_DOMAIN variable for all the above based on the environment.

Continuous deployment to production: Enables Auto Deploy with master branch directly deployed to production.

Continuous deployment to production using timed incremental rollout

Automatic deployment to staging, manual deployment to production

Auto Build creates a build of the application using an existing Dockerfile or Heroku buildpacks.

If a project’s repository contains a Dockerfile, Auto Build will use docker build to create a Docker image.

Each buildpack requires certain files to be in your project’s repository for Auto Build to successfully build your application.

Auto Test automatically runs the appropriate tests for your application using Herokuish and Heroku buildpacks by analyzing your project to detect the language and framework.

Auto Code Quality uses the Code Quality image to run static analysis and other code checks on the current code.

Static Application Security Testing (SAST) uses the SAST Docker image to run static analysis on the current code and checks for potential security issues.

Dependency Scanning uses the Dependency Scanning Docker image to run analysis on the project dependencies and checks for potential security issues.

License Management uses the License Management Docker image to search the project dependencies for their license.

Vulnerability Static Analysis for containers uses Clair to run static analysis on a Docker image and checks for potential security issues.

Review Apps are temporary application environments based on the branch’s code so developers, designers, QA, product managers, and other reviewers can actually see and interact with code changes as part of the review process. Auto Review Apps create a Review App for each branch. Auto Review Apps will deploy your app to your Kubernetes cluster only. When no cluster is available, no deployment will occur.

The Review App will have a unique URL based on the project ID, the branch or tag name, and a unique number, combined with the Auto DevOps base domain.

Your apps should not be manipulated outside of Helm (using Kubernetes directly).

Dynamic Application Security Testing (DAST) uses the popular open source tool OWASP ZAProxy to perform an analysis on the current code and checks for potential security issues.

Auto Browser Performance Testing utilizes the Sitespeed.io container to measure the performance of a web page.

add the paths to a file named .gitlab-urls.txt in the root directory, one per line.

After a branch or merge request is merged into the project’s default branch (usually master), Auto Deploy deploys the application to a production environment in the Kubernetes cluster, with a namespace based on the project name and unique project ID

Auto Deploy doesn’t include deployments to staging or canary by default, but the Auto DevOps template contains job definitions for these tasks if you want to enable them.

For internal and private projects a GitLab Deploy Token will be automatically created, when Auto DevOps is enabled and the Auto DevOps settings are saved.

If the GitLab Deploy Token cannot be found, CI_REGISTRY_PASSWORD is used. Note that CI_REGISTRY_PASSWORD is only valid during deployment.

If present, DB_INITIALIZE will be run as a shell command within an application pod as a helm post-install hook.

a post-install hook means that if any deploy succeeds, DB_INITIALIZE will not be processed thereafter.

DB_MIGRATE will be run as a shell command within an application pod as a helm pre-upgrade hook.

Once your application is deployed, Auto Monitoring makes it possible to monitor your application’s server and response metrics right out of the box.

annotate the NGINX Ingress deployment to be scraped by Prometheus using prometheus.io/scrape: "true" and prometheus.io/port: "10254"

While Auto DevOps provides great defaults to get you started, you can customize almost everything to fit your needs; from custom buildpacks, to Dockerfiles, Helm charts, or even copying the complete CI/CD configuration into your project to enable staging and canary deployments, and more.

Auto DevOps uses Helm to deploy your application to Kubernetes.

make use of the HELM_UPGRADE_EXTRA_ARGS environment variable to override the default values in the values.yaml file in the default Helm chart.

specify the use of a custom Helm chart per environment by scoping the environment variable to the desired environment.

Your additions will be merged with the Auto DevOps template using the behaviour described for include

copy and paste the contents of the Auto DevOps template into your project and edit this as needed.

In order to support applications that require a database, PostgreSQL is provisioned by default.

Set up the replica variables using a project variable and scale your application by just redeploying it!

You should not scale your application using Kubernetes directly.

Some applications need to define secret variables that are accessible by the deployed application.

Auto DevOps pipelines will take your application secret variables to populate a Kubernetes secret.

Environment variables are generally considered immutable in a Kubernetes pod.

If STAGING_ENABLED is defined in your project (e.g., set STAGING_ENABLED to 1 as a CI/CD variable), then the application will be automatically deployed to a staging environment, and a production_manual job will be created for you when you’re ready to manually deploy to production.

If CANARY_ENABLED is defined in your project (e.g., set CANARY_ENABLED to 1 as a CI/CD variable) then two manual jobs will be created: canary which will deploy the application to the canary environment production_manual which is to be used by you when you’re ready to manually deploy to production.

If INCREMENTAL_ROLLOUT_MODE is set to manual in your project, then instead of the standard production job, 4 different manual jobs will be created: rollout 10% rollout 25% rollout 50% rollout 100%

To start a job, click on the play icon next to the job’s name.

not all buildpacks support Auto Test yet

When a project has been marked as private, GitLab’s Container Registry requires authentication when downloading containers.

Authentication credentials will be valid while the pipeline is running, allowing for a successful initial deployment.

We strongly advise using GitLab Container Registry with Auto DevOps in order to simplify configuration and prevent any unforeseen issues.

a better way is to keep a role in its own repository.

The best way to make shared roles available to your playbooks is to use a function built into Ansible itself: by using the command ansible-galaxy

requirements.yml ensures that the used role can be pinned to a certain release tag value, commit hash, or branch name.

Each time Ansible Tower checks out a project it looks for a roles/requirements.yml. If such a file is present, a new version of each listed role is copied to the local checkout of the project and thus available to the relevant playbooks.

stick to the directory name roles, sitting in the root of your project directory.

have one requirements.yml only, and keep it at roles/requirements.yml

the desire for an interactive approval step between plan and apply.

terraform init -input=false to initialize the working directory.

terraform plan -out=tfplan -input=false to create a plan and save it to the local file tfplan.

terraform apply -input=false tfplan to apply the plan stored in the file tfplan.

the environment variable TF_IN_AUTOMATION is set to any non-empty value, Terraform makes some minor adjustments to its output to de-emphasize specific commands to run.

it can be difficult or impossible to ensure that the plan and apply subcommands are run on the same machine, in the same directory, with all of the same files present.

to allow only one plan to be outstanding at a time.

forcing plans to be approved (or dismissed) in sequence

The -auto-approve option tells Terraform not to require interactive approval of the plan before applying it.

obtain the archive created in the previous step and extract it at the same absolute path. This re-creates everything that was present after plan, avoiding strange issues where local files were created during the plan step.

a "build artifact"

Within your Terraform configuration, you may include the name of the current workspace using the ${terraform.workspace} interpolation sequence.

changing behavior based on the workspace.

Named workspaces allow conveniently switching between multiple instances of a single configuration within its single backend.

A common use for multiple workspaces is to create a parallel, distinct copy of a set of infrastructure in order to test a set of changes before modifying the main production infrastructure.

Non-default workspaces are often related to feature branches in version control.

In particular, organizations commonly want to create a strong separation between multiple deployments of the same infrastructure serving different development stages (e.g. staging vs. production) or different internal teams.

use one or more re-usable modules to represent the common elements, and then represent each instance as a separate configuration that instantiates those common elements in the context of a different backend.

If a Terraform state for one configuration is stored in a remote backend that is accessible to other configurations then terraform_remote_state can be used to directly consume its root module outputs from those other configurations.

For server addresses, use a provider-specific resource to create a DNS record with a predictable name and then either use that name directly or use the dns provider to retrieve the published addresses in other configurations.

using a remote backend instead is recommended when there are multiple collaborators.

Nginx is built to handle many concurrent connections at the same time.

provides you with flexibility in easily adding backend servers or taking them down as needed for maintenance

Proxying in Nginx is accomplished by manipulating a request aimed at the Nginx server and passing it to other servers for the actual processing

When a request matches a location with a proxy_pass directive inside, the request is forwarded to the URL given by the directive

The request coming from Nginx on behalf of a client will look different than a request coming directly from a client

Nginx gets rid of any empty headers

Nginx, by default, will consider any header that contains underscores as invalid. It will remove these from the proxied request

The "Host" header is re-written to the value defined by the $proxy_host variable.

The upstream should not expect this connection to be persistent

Headers with empty values are completely removed from the passed request.

by default, this will be set to the value of $proxy_host, a variable that will contain the domain name or IP address and port taken directly from the proxy_pass definition

This is selected by default as it is the only address Nginx can be sure the upstream server responds to

$http_host: Sets the "Host" header to the "Host" header from the client request.

preference to: the host name from the request line itself

set the "Host" header to the $host variable. It is the most flexible and will usually provide the proxied servers with a "Host" header filled in as accurately as possible

This variable takes the value of the original X-Forwarded-For header retrieved from the client and adds the Nginx server's IP address to the end.

Once defined, this name will be available for use within proxy passes as if it were a regular domain name

By default, this is just a simple round-robin selection process (each request will be routed to a different host in turn)

Specifies that new connections should always be given to the backend that has the least number of active connections.

distributes requests to different servers based on the client's IP address.

mainly used with memcached proxying

As for the hash method, you must provide the key to hash against

Server Weight

Nginx's buffering and caching capabilities

Without buffers, data is sent from the proxied server and immediately begins to be transmitted to the client.

With buffers, the Nginx proxy will temporarily store the backend's response and then feed this data to the client

Nginx defaults to a buffering design

can be set in the http, server, or location contexts.

the sizing directives are configured per request, so increasing them beyond your need can affect your performance

When buffering is "off" only the buffer defined by the proxy_buffer_size directive will be used

A high availability (HA) setup is an infrastructure without a single point of failure, and your load balancers are a part of this configuration.

multiple load balancers (one active and one or more passive) behind a static IP address that can be remapped from one server to another.

Nginx also provides a way to cache content from backend servers

proxy_cache backcache;

The proxy_cache_bypass directive is set to the $http_cache_control variable. This will contain an indicator as to whether the client is explicitly requesting a fresh, non-cached version of the resource

For private content, you should set the Cache-Control header to "no-cache", "no-store", or "private" depending on the nature of the data

we like HTTPS/non-www since HTTPS is needed for current browsers and non-www is short.

visit the Mozilla TLS Generator to get the latest cipher suites and TLS versions

add the necessary headers for GeoIP and proper logging.

HTML5 SSE simpler than websockets

nginx -t

Scan your site with SSL Labs scan

globalLock.totalTime: If this is higher than the total database uptime, the database has been in a lock state for too long.

Unlike relational databases such as MySQL or PostgreSQL, MongoDB uses JSON-like documents for storing data.

Databases operate in an environment that consists of numerous reads, writes, and updates.

When a lock occurs, no other operation can read or modify the data until the operation that initiated the lock is finished.

locks.deadlockCount: Number of times the lock acquisitions have encountered deadlocks

Is the database frequently locking from queries? This might indicate issues with the schema design, query structure, or system architecture.

For version 3.2 on, WiredTiger is the default.

MMAPv1 locks whole collections, not individual documents.

When the MMAPv1 storage engine is in use, MongoDB will use memory-mapped files to store data.

db.serverStatus().mem

mem.resident: Roughly equivalent to the amount of RAM in megabytes that the database process uses

If mem.resident exceeds the value of system memory and there’s a large amount of unmapped data on disk, we’ve most likely exceeded system capacity.

If the value of mem.mapped is greater than the amount of system memory, some operations will experience page faults.

The WiredTiger storage engine is a significant improvement over MMAPv1 in performance and concurrency.

By default, MongoDB will reserve 50 percent of the available memory for the WiredTiger data cache.

wiredTiger.cache.bytes currently in the cache – This is the size of the data currently in the cache.

wiredTiger.cache.tracked dirty bytes in the cache – This is the size of the dirty data in the cache.

we can look at the wiredTiger.cache.bytes read into cache value for read-heavy applications. If this value is consistently high, increasing the cache size may improve overall read performance.

check whether the application is read-heavy. If it is, increase the size of the replica set and distribute the read operations to secondary members of the set.

Replication is the propagation of data from one node to another

Replication sets handle this replication.

Sometimes, data isn’t replicated as quickly as we’d like.

use the db.printSlaveReplicationInfo() or the rs.printSlaveReplicationInfo() command to see the status of a replica set from the perspective of the secondary member of the set.

shows how far behind the secondary members are from the primary. This number should be as low as possible.

monitor this metric closely.

watch for any spikes in replication delay.

One replica set is primary. All others are secondary.

use the profiler to gain a deeper understanding of the database’s behavior.

Enabling the profiler can affect system performance, due to the additional activity.

The values of fields may include other documents, arrays, and arrays of documents.

reduce need for expensive joins

MongoDB stores documents in collections.

Read-only Views

Indexes support faster queries and can include keys from embedded documents and arrays.

MongoDB's replication facility, called replica set

A replica set is a group of MongoDB servers that maintain the same data set, providing redundancy and increasing data availability.

Sharding distributes data across a cluster of machines.

MongoDB supports creating zones of data based on the shard key.

MongoDB provides pluggable storage engine API

The generate attribute is used to inform Terragrunt to generate the Terraform code for configuring the backend.

The find_in_parent_folders() helper will automatically search up the directory tree to find the root terragrunt.hcl and inherit the remote_state configuration from it.

Unlike the backend configurations, provider configurations support variables,

if you needed to modify the configuration to expose another parameter (e.g session_name), you would have to then go through each of your modules to make this change.

instructs Terragrunt to create the file provider.tf in the working directory (where Terragrunt calls terraform) before it calls any of the Terraform commands

large modules should be considered harmful.

Large modules are slow, insecure, hard to update, hard to code review, hard to test, and brittle (i.e., you have all your eggs in one basket).

Terragrunt allows you to define your Terraform code once and to promote a versioned, immutable “artifact” of that exact same code from environment to environment.

算數邏輯單元與控制單元。其中算數邏輯單元主要負責程式運算與邏輯判斷，控制單元則主要在協調各周邊元件與各單元間的工作。

資料會先寫入到主記憶體，然後 CPU 才能開始應用

CPU 其實內部已經含有一些微指令，我們所使用的軟體都要經過 CPU 內部的微指令集來達成才行。

世界上常見到的兩種主要 CPU 架構， 分別是：精簡指令集 (RISC) 與複雜指令集 (CISC) 系統。

微指令集較為精簡，每個指令的執行時間都很短，完成的動作也很單純，指令的執行效能較佳； 但是若要做複雜的事情，就要由多個指令來完成。

CISC在微指令集的每個小指令可以執行一些較低階的硬體操作，指令數目多而且複雜， 每條指令的長度並不相同。因為指令執行較為複雜所以每條指令花費的時間較長， 但每條個別指令可以處理的工作較為豐富。

最早的那顆Intel發展出來的CPU代號稱為8086

AMD依此架構修改新一代的CPU為64位元

CPU 位元指的是CPU一次資料讀取的最大量！64位元CPU代表CPU一次可以讀寫64bits這麼多的資料

因為CPU讀取資料量有限制，因此能夠從記憶體中讀寫的資料也就有所限制

：(1)北橋：負責連結速度較快的CPU、主記憶體與顯示卡界面等元件；

(2)南橋：負責連接速度較慢的裝置介面， 包括硬碟、USB、網路卡等等。不過由於北橋最重要的就是 CPU 與主記憶體之間的橋接，因此目前的主流架構中， 大多將北橋記憶體控制器整合到 CPU 封裝當中

CPU 與可接受的晶片組是有搭配性的，尤其目前每種 CPU 的腳位都不一樣

時脈越高，代表單位時間內可進行的工作越多

大概都只看總頻寬或基準時脈

CPU 時脈越高的情況下，會產生很多諸如散熱、設計及與週邊元件溝通的問題。

其他的程序還在等待 CPU ，但是 CPU 又在等待 I/O

Intel 在同一個運算核心底下安裝兩個暫存器來模擬出另一個核心，實際上是兩個暫存器 (可以想成是程式的執行器) 共用一個實體核心。 這就是超執行緒的簡易認知

時脈的意思是每秒鐘能夠進行的工作次數，而每次工作能夠讀進的資料量就是位元數

每個用戶端大多是短時間的大運算，所以通常不會有一隻程序一直佔用著系統資源。

CPU 的所有資料都是從記憶體讀寫來的，所以記憶體的容量與頻寬就相當的重要了

DRAM 根據技術的更新又分好幾代，而使用上較廣泛的有所謂的 SDRAM 與 DDR SDRAM 兩種。 這兩種記憶體的差別除了在於腳位與工作電壓上的不同之外，DDR 是所謂的雙倍資料傳送速度 (Double Data Rate)

晶片組廠商就將兩個主記憶體彙整在一起，如果一支記憶體可達 64 位元，兩支記憶體就可以達到 128 位元了，這就是雙通道的設計理念。 在某些比較多核心的伺服器主機上面，甚至還使用了 3 通道到 4 通道的設計

CPU 內部的暫存器與少量記憶體被稱為第一、第二層快取 (L1, L2 cache)，而放在核心間的快取記憶體就被稱為第三層快取記憶體 (L3 cache)

CPU 的暫存器是直接設計在 CPU 核心內部，可以用來幫助 CPU 的運算。

在多核心 CPU 的核心之間，會有另一個共享的快取記憶體存在，讓所有的 CPU 核心可以共享某些資源。

靜態隨機存取記憶體 (Static Random Access Memory, SRAM)

各項參數， 是被記錄到主機板上頭的一個稱為 CMOS 的晶片上，這個晶片需要藉著額外的電源來發揮記錄功能， 這也是為什麼你的主機板上面會有一顆電池的緣故。

BIOS(Basic Input Output System)是一套程式，這套程式是寫死到主機板上面的一個記憶體晶片中， 這個記憶體晶片在沒有通電時也能夠將資料記錄下來，那就是唯讀記憶體(Read Only Memory, ROM)。

BIOS對於個人電腦來說是非常重要的， 因為他是系統在開機的時候首先會去讀取的一個小程式喔

韌體(firmware)很多也是使用ROM來進行軟體的寫入的。 韌體像軟體一樣也是一個被電腦所執行的程式，然而他是對於硬體內部而言更加重要的部分。例如BIOS就是一個韌體， BIOS雖然對於我們日常操作電腦系統沒有什麼太大的關係，但是他卻控制著開機時各項硬體參數的取得！

現在的 BIOS 通常是寫入類似快閃記憶體 (flash) 或 EEPROM

顯示卡能夠傳輸的資料量當然也是越大越好！這時就得要考慮到傳輸的界面了！當前 (2018) 主流的傳輸界面為 PCI-E，這個 PCI-E 又有三種版本， version 1, 2, 3 ，這三個版本的速度並不相同

PCI-E (PCI-Express) 使用的是類似管線的概念來處理，在 PCI-E 第一版中，每條管線可以具有 250MBytes/s 的頻寬效能，管線越多(通常設計到 x16 管線)則總頻寬越高

通常 CPU 製造商會根據 CPU 來設計搭配的南橋晶片，由於現在只有一個晶片 (北橋整合到 CPU 內了)，所以目前只有一顆主機板晶片組。

插槽上面的資料要傳輸到 CPU 就得要經過晶片組，然後透過 DMI 通道傳上去！所以，在某些情況下，系統的效能會被卡住在這條通道上喔！

晶片組接的設備相當多喔！有 PCI-E 插槽、USB設備、網路設備、音效設備、硬碟設備等，這全部的裝置共用那一條 DMI 喔！ 所以，整個系統效能的瓶頸通常不在 CPU 啦！通常就是在南橋接的設備上面！所以，當你有非常複雜的程式要運作的時候，讓這些程式越少通過南橋， 他的系統效能就會比較好一點

物理組成

讀寫主要是透過在機械手臂上的讀取頭(head)來達成

由於磁碟盤是圓的，並且透過機器手臂去讀寫資料，磁碟盤要轉動才能夠讓機器手臂讀寫。

磁碟的最小物理儲存單位，稱之為磁區 (sector)，那同一個同心圓的磁區組合成的圓就是所謂的磁軌(track)。 由於磁碟裡面可能會有多個磁碟盤，因此在所有磁碟盤上面的同一個磁軌可以組合成所謂的磁柱 (cylinder)。

通常資料的讀寫會由外圈開始往內寫

目前主流的硬碟連接界面就是 SATA

雖然 SATA III 界面理論傳輸可到達 600Mbytes/s，不過傳統硬碟由於物理設計的限制因素，通常存取速度效能大多在 150~200Mbytes/s 之間

串列式 SCSI (Serial Attached SCSI, SAS)

傳統硬碟有個很致命的問題，就是需要驅動馬達去轉動磁碟盤～這會造成很嚴重的磁碟讀取延遲

快閃記憶體去製作成高容量的設備

沒有讀寫頭與磁碟盤啊！都是記憶體！

各個繪圖卡的運算晶片 (GPU) 設計的理念不同，加上驅動程式與軟體搭配的問題，並不是一張高效能繪圖卡就可以完勝其他的繪圖卡， 還得要注意相關的軟體才行。

Linux的核心是由Linus Torvalds在1991年的時候給他開發出來的， 並且丟到網路上提供大家下載，後來大家覺得這個小東西(Linux Kernel)相當的小而精巧， 所以慢慢的就有相當多的朋友投入這個小東西的研究領域裡面去

1960年代初期麻省理工學院(MIT)發展了所謂的： 『相容分時系統(Compatible Time-Sharing System, CTSS)』， 它可以讓大型主機透過提供數個終端機(terminal)以連線進入主機，來利用主機的資源進行運算工作

為了更加強化大型主機的功能，以讓主機的資源可以提供更多使用者來利用，所以在1965年前後， 由貝爾實驗室(Bell)、麻省理工學院(MIT)及奇異公司(GE, 或稱為通用電器)共同發起了Multics的計畫

以組合語言(Assembler)寫出了一組核心程式，同時包括一些核心工具程式， 以及一個小小的檔案系統。那個系統就是Unix的原型！ 當時Thompson將Multics龐大的複雜系統簡化了不少，於是同實驗室的朋友都戲稱這個系統為：Unics。(當時尚未有Unix的名稱)

Dennis Ritchie (註3) 將B語言重新改寫成C語言，再以C語言重新改寫與編譯Unics的核心， 最後正名與發行出Unix的正式版本！

由於Unix是以較高階的C語言寫的，相對於組合語言需要與硬體有密切的配合， 高階的C語言與硬體的相關性就沒有這麼大了！所以，這個改變也使得Unix很容易被移植到不同的機器上面喔！

AT&T此時對於Unix是採取較開放的態度，此外，Unix是以高階的C語言寫成的， 理論上是具有可移植性的！亦即只要取得Unix的原始碼，並且針對大型主機的特性加以修訂原有的原始碼(Source Code)， 就可能將Unix移植到另一部不同的主機上頭了。

柏克萊大學的Bill Joy (註4)在取得了Unix的核心原始碼後，著手修改成適合自己機器的版本， 並且同時增加了很多工具軟體與編譯程式，最終將它命名為Berkeley Software Distribution (BSD)。

每一家公司自己出的Unix雖然在架構上面大同小異，但是卻真的僅能支援自身的硬體， 所以囉，早先的Unix只能與伺服器(Server)或者是大型工作站(Workstation)劃上等號！

AT&T在1979年發行的第七版Unix中，特別提到了 『不可對學生提供原始碼』的嚴格限制！

純種的Unix指的就是System V以及BSD

AT&T自家的System V

既然1979年的Unix第七版可以在Intel的x86架構上面進行移植， 那麼是否意味著可以將Unix改寫並移植到x86上面了呢？在這個想法上， 譚寧邦教授於是乎自己動手寫了Minix這個Unix Like的核心程式！

『既然作業系統太複雜，我就先寫可以在Unix上面運行的小程式，這總可以了吧？』

如果能夠寫出一個不錯的編譯器，那不就是大家都需要的軟體了嗎？ 因此他便開始撰寫C語言的編譯器，那就是現在相當有名的GNU C Compiler(gcc)！

他還撰寫了更多可以被呼叫的C函式庫(GNU C library)，以及可以被使用來操作作業系統的基本介面BASH shell！ 這些都在1990年左右完成了！

有鑑於圖形使用者介面(Graphical User Interface, GUI) 的需求日益加重，在1984年由MIT與其他協力廠商首次發表了X Window System ，並且更在1988年成立了非營利性質的XFree86這個組織。所謂的XFree86其實是 X Window System + Free + x86的整合名稱呢！

譚寧邦教授為了教育需要而撰寫的Minix系統！ 他在購買了最新的Intel 386的個人電腦後，就立即安裝了Minix這個作業系統。 另外，上個小節當中也談到，Minix這個作業系統是有附上原始碼的， 所以托瓦茲也經由這個原始碼學習到了很多的核心程式設計的設計概念喔！

托瓦茲自己也說：『我始終是個性能癖』^_^。 為了徹底發揮386的效能，於是托瓦茲花了不少時間在測試386機器上！ 他的重要測試就是在測試386的多功性能。首先，他寫了三個小程式，一個程式會持續輸出A、一個會持續輸出B， 最後一個會將兩個程式進行切換。他將三個程式同時執行，結果，他看到螢幕上很順利的一直出現ABABAB...... 他知道，他成功了！ ^_^

為了讓所有的軟體都可以在Linux上執行，於是托瓦茲開始參考標準的POSIX規範。

POSIX是可攜式作業系統介面(Portable Operating System Interface)的縮寫，重點在規範核心與應用程式之間的介面， 這是由美國電器與電子工程師學會(IEEE)所發佈的一項標準喔

因為托瓦茲放置核心的那個FTP網站的目錄為：Linux， 從此，大家便稱這個核心為Linux了。(請注意，此時的Linux就是那個kernel喔！ 另外，托瓦茲所丟到該目錄下的第一個核心版本為0.02呢！)

Linux其實就是一個作業系統最底層的核心及其提供的核心工具。 他是GNU GPL授權模式，所以，任何人均可取得原始碼與可執行這個核心程式，並且可以修改。

Linux參考POSIX設計規範，於是相容於Unix作業系統，故亦可稱之為Unix Like的一種

為了讓使用者能夠接觸到Linux，於是很多的商業公司或非營利團體， 就將Linux Kernel(含tools)與可運行的軟體整合起來，加上自己具有創意的工具程式， 這個工具程式可以讓使用者以光碟/DVD或者透過網路直接安裝/管理Linux系統。 這個『Kernel + Softwares + Tools + 可完整安裝程序』的咚咚，我們稱之為Linux distribution， 一般中文翻譯成可完整安裝套件，或者Linux發佈商套件等。

在1994年終於完成的Linux的核心正式版！version 1.0。 這一版同時還加入了X Window System的支援呢！且於1996年完成了2.0版、2011 年釋出 3.0 版，更於 2015 年 4 月釋出了 4.0 版哩！ 發展相當迅速喔！此外，托瓦茲指明了企鵝為Linux的吉祥物。

Linux本身就是個最陽春的作業系統，其開發網站設立在http://www.kernel.org，我們亦稱Linux作業系統最底層的資料為『核心(Kernel)』。

常見的 Linux distributions 分類有『商業、社群』分類法，或『RPM、DPKG』分類法

事實上鳥哥認為distributions主要分為兩大系統，一種是使用RPM方式安裝軟體的系統，包括Red Hat, Fedora, SuSE等都是這類； 一種則是使用Debian的dpkg方式安裝軟體的系統，包括Debian, Ubuntu, B2D等等。

In full backups, two types of operations are performed to make the database consistent: committed transactions are replayed from the log file against the data files, and uncommitted transactions are rolled back.

You should use the --apply-log-only option to prevent the rollback phase.

An incremental backup copies each page whose LSN is newer than the previous incremental or full backup’s LSN.

Incremental backups do not actually compare the data files to the previous backup’s data files.

Incremental backups simply read the pages and compare their LSN to the last backup’s LSN.

The xtrabackup binary writes a file called xtrabackup_checkpoints into the backup’s target directory. This file contains a line showing the to_lsn, which is the database’s LSN at the end of the backup.