2024年4月1日 星期一

Cygwin vs MinGW vs Msys

Quote Cygwin、Msys、MinGW、Msys2的區別與聯繫_msys2和mingw-CSDN博客

區別:
  • Cygwin是類比 POSIX 系統,源碼移植 Linux 應用到 Windows 下
  • MinGW 是用於開發 Windows 應用的開發環境。
  • Msys
  • Msys2

聯繫:
  • 均提供了部分 Linux 下的應用,多跑在 Windows 上
  • MinGW 作為 Cygwin 下的軟體包,可以在 Cygwin 上運行

Cygwin,原 Cygnus 出品(已被紅帽收購),目前是 RedHat 名下的專案。 專案的目的是提供運行於 Windows 平臺的類 Unix 環境(以 GNU 工具為代表),為了達到這個目的,Cygwin 提供了一套抽象層 dll,用於將部分 Posix 調用轉換成 Windows 的 API 調用,實現相關功能。 這裡面最典型的,最基本的類比層就是那個 cygwin1.dll。 除此之外,隨著Linux系統的發展壯大,目前的 Cygwin 已經不僅僅提供POSIX相容,因此也順帶多了更多類比層的依賴關係。

Cygwin 的目錄結構基本照搬了 linux 的樣子,但同時,也相容了 Windows 的許多功能:大部分應用使用 Unix 風格的路徑,Windows的盤符通過類似掛載點的方式提供給 Cygwin 使用;Cygwin 中既可以運行 Cygwin 的應用(依賴模擬層),又可以運行 Windows 應用,而傳遞給應用的路徑會經過它的類比層變換,以此保證程式運行不會出錯。

由於它的類比層實現了相當良好的 Posix 相容,人們試著將許多重要的 Linux/BSD 應用移植到了Cygwin下,使得Cygwin越來越大,功能也越來越豐富,以至於目前很多人直接把將Linux應用移植到Windows平臺的任務都交給了Cygwin(當然,這種移植並非原生)。 事實上,Cygwin誕生之初,本就是想通過GCC編譯出Windows應用來,因為bootstrap GCC而順帶搞了一坨別的東西過來,最後發展到現在的。

小結:Cygwin是運行於Windows平臺的POSIX“子系統”,提供Windows下的類Unix環境,並提供將部分 Linux 應用“移植”到Windows平臺的開發環境的一套軟體。 按照我經常開玩笑的話來講,Cygwin 基本上就是傳說中的 GNU/NT 系統(對照 GNU/Linux,GNU/BSD,GNU/HURD)。



MinGW, Minimalist GNU for Windows,開發原生(32位) Windows 應用的開發環境。 它主要提供了針對 win32 應用的 GCC、GNU binutils 等工具,以及對等於 Windows SDK(的子集)的頭文件和用於 MinGW 版本 linker 的庫檔(so、a等,而不是 VC 的 lib)。

MinGW 能夠替代 cl 用於編譯不包含 MFC 的、以 WinSDK 為主的 Windows 應用,並且編譯出來的應用不依賴於第三方的模擬層支援,其運行時為大部分 Windows 標配的 msvcrt(故稱原生 Windows 應用)。 除此之外,MinGW 也支援 GCC 支援的其他語言。

因為這些原因,MinGW 被許多 Linux 上發展起來的開發工具選擇為 Windows 版本的預設編譯器,例如 CodeBlocks,例如 DevC++。

小結,MinGW 是用於進行 Windows 應用開發的 GNU 工具鏈(開發環境),它的編譯產物一般是原生 Windows 應用,雖然它本身不一定非要運行在 Windows 系統下(是的 MinGW 工具鏈也存在於 Linux、BSD 甚至 Cygwin 下)。



MSYS,由於 MinGW 本身僅代表工具鏈,而在 Windows 下,由於那個shi一樣的cmd,以及配套的命令行工具不夠齊全(也不舒服),因此,MinGW 開發者從曾經比較舊的 Cygwin 創建了一個分支,也用於提供類 Unix 環境。 但與 Cygwin 的大而全不同,MSYS 是衝著小巧玲瓏的目標去的,所以整套 MSYS 以及 MinGW,主要以基本的 Linux 工具為主,大小在 200M 左右,並且沒有多少擴展能力。

MSYS 是用於輔助 Windows 版 MinGW 進行命令行開發的配套軟體包,提供了部分 Unix 工具以使得 MinGW 的工具使用起來方便一些。 如果不喜歡龐大的 Cygwin,而且使用不多,可以試試。 不過喜歡完整體驗、不在乎磁碟佔用等等,還是推薦 Cygwin 而不是 MSYS。



MinGW-w64,前面提到的MinGW,是針對32位 Windows 應用開發的。 而且由於版本問題,不能很好的支援較新的 Windows API。 MinGW-W64 則是新一代的 MinGW,支援更多的 API,支援 64 位應用開發,甚至支援 32 位 host 編譯 64 位應用以及反過來的“交叉”編譯。 除此之外,它本身也有 32 位和 64 位不同版本,其它與 MinGW 相同。



MSYS2,由於 MinGW 萬年不更新,MSYS 更是,Cygwin的許多新功能 MSYS 沒有同步過來,於是 Alex 等人建立了新一代的 MSYS 專案。 仍然是 fork 了 Cygwin(較新版),但有個更優秀的包管理員 pacman,有活躍的開發者跟使用者組,有大量預編譯的軟體包(雖然肯定沒有Cygwin多)...... 對於不喜歡龐大的 Cygwin 的使用者而言,推薦試試 msys2。

Cygwin vs WSL

Cygwin : CYGnus WINdows
WSL : Windows Subsystem for Linux

Quote

Cygwin is a POSIX compatibility layer that runs on top of the Win32 subsystem. It has approximately nothing to do with Linux; it can broadly be treated as "just another Unix-like" where porting programs requires recompilation and possibly source modification, and anything that requires non-POSIX Linux-specific features probably won't work.

WSL 1 is designed to be ABI-compatible with Linux proper. It does not use the real Linux kernel, but is compatible such that programs compiled for Linux can run on it without recompilation or translation. WSL is part of the NT kernel, so exists independently of the Win32 subsystem. This is similar to the older SUA, though that was a POSIX (not Linux!) subsystem on top of the NT kernel.

WSL 2, runs a real Linux kernel on a lightweight VM. It promises similar Windows integration as WSL 1 but with a real Linux kernel (so kernel modules, filesystems, etc., should work). It also has proper GUI support (on Windows 10 Build 19044+ or Windows 11) but has reduced I/O performance when accessing Windows filesystems compared to WSL 1.


2024年2月1日 星期四

Access / Modify / Change time of Linux 'stat'

Difference between Access, Modification and Change Time in Linux? (dextutor.com)

Access Time: is the time when the file was last accessed or read. For example, using the cathead or an editor. But remember you did not modify the contents.

Modification Time: is the time when the contents of the file was last modified. For example, you used an editor to add new content or delete some existing content.

Change Time: is the time when the file’s inode has been changed. For example, by changing permissions, ownership, file name, number of hard links.

2024年1月30日 星期二

[Handbook] Linux 'screen'

there are screens in the list, but "no screen to be resumed" - Unix & Linux Stack Exchange 

Q: there are screens in the list, but "no screen to be resumed"

[root@server chiliNUT]# screen -r
There is a screen on:
27863.pts-1.server (Attached)
There is no screen to be resumed.

A: Use screen -d -r


2023年12月29日 星期五

RESTful design

ChatGPT answers "What does RESTful design refer to?":

RESTful design, or Representational State Transfer, is an architectural style for designing networked applications. It was introduced by Roy Fielding in his doctoral dissertation in 2000. REST is not a protocol but rather a set of constraints and principles that, when applied to a system, help create scalable, maintainable, and loosely coupled web services.

Here are the key principles of RESTful design:

  1. Stateless Communication:

    • Each request from a client to a server must contain all the information needed to understand and fulfill the request. The server should not store any information about the client between requests. Each request from a client to a server must contain all the information needed to understand and fulfill the request.
  2. Client-Server Architecture:

    • The client and server are separate entities that communicate over a network. The client is responsible for the user interface and user experience, while the server is responsible for processing requests, managing resources, and handling business logic.
  3. Uniform Interface:

    • RESTful APIs should have a consistent and uniform interface. This principle is further divided into several constraints:
      • Resource Identification: Resources (such as data objects or services) are identified by URIs (Uniform Resource Identifiers).
      • Resource Manipulation through Representations: Resources are manipulated using representations, and these representations can be in various formats (e.g., JSON, XML).
      • Self-Descriptive Messages: Each message from the server to the client should include enough information to describe how to process the message.
      • Hypermedia as the Engine of Application State (HATEOAS): Clients interact with the application entirely through hypermedia provided dynamically by the application servers.
  4. Stateless Communication:

    • Each request from a client to a server must contain all the information needed to understand and fulfill the request. The server should not store any information about the client between requests.
  5. Cacheability:

    • Responses from the server can be explicitly marked as cacheable or non-cacheable. This improves efficiency and scalability by allowing clients to cache responses.
  6. Layered System:

    • A client cannot ordinarily tell whether it is connected directly to the end server or to an intermediary along the way. Intermediary servers (proxies, gateways, etc.) can be added to improve scalability or enforce security without impacting the client.

RESTful design is commonly used in the development of web services, including APIs (Application Programming Interfaces) for IoT devices, web applications, and mobile applications. It emphasizes simplicity, scalability, and the decoupling of components, making it a popular choice for building distributed systems on the web.