Kasaysayan ng mga Linux distribution

Ano talaga ang isang Linux distribution

Nagsisimula ang kasaysayan ng Linux distributions sa isang kakulangan: ang Linux kernel, kapag mag-isa, ay walang kayang gawin na magagamit ng tao. Nagbo-boot ito at hinahanap ang hardware. Pagkatapos, tumitigil ito. Kailangang magdagdag ang isang grupo ng userland, pumili kung paano ini-install at ina-update ang software, at mangakong patuloy itong aayusin sa loob ng maraming taon. Ang distribution ay ang hanay ng mga pagpiling iyon, kasama ang grupong nananatiling nagme-maintain nito pagkatapos.

Mayroon itong limang bahagi. Kapag binago ang alinman sa mga ito, ibang distribution na iyon, kahit pareho ang karamihan sa mga binary:

• Isang kernel sa bersyong pinili ng proyekto, kasama ang mga patch at driver na idinagdag nito.
• Isang userland: ang C library, ang shell, ang init system, at ang mga standard command.
• Isang package format at ang tool na nag-i-install nito.
• Isang release policy: kung ano ang maaaring magbago, gaano kadalas, at gaano katagal aayusin ang bawat release.
• Mga tao: package maintainer, security team, at taong sasagot kapag may package na nagkaaberya.

Ang kernel ang magkakaparehong bahagi, kaya mas magkalapit ang dalawang Linux distribution sa isa't isa kaysa sa alinman sa mga ito sa ibang Unix. Mahalagang tandaan ito kapag ikinukumpara ang Linux at FreeBSD bilang mga server platform, kung saan iisang proyekto ang bumubuo sa kernel at base userland at sabay na nagre-release ng mga ito. Sa Linux, magkahiwalay na upstream ang pinagmumulan ng mga bahaging iyon, at ang distribution ang nagsisiguro na nagtutugma ang mga ito.

Kasaysayan ng mga Linux distribution sa tatlong pamilya

Nagsimula noong 1993 at 1994 ang tatlong project na naging mga pamilya: Slackware, Debian, at Red Hat. Halos lahat ng image sa VPS control panel ngayon ay isa sa mga ito o descendant ng isa sa mga ito. Namamana ng descendant ang package format, file layout, at karaniwan ding release practices, kaya nananatiling parang Debian ang isang Debian derivative kahit wala na ang dating branding.

Nararapat na hiwalay na banggitin ang mga independent, dahil wala silang pinag-fork-an. Ang Arch, Gentoo, Alpine, NixOS, at Void ay gumawa ng sarili nilang package manager at mga panuntunan. Dalawa sa mga ito, ang Arch at Alpine, ay napabilang pa rin sa image list ng provider mo dahil sa mga dahilan na walang kinalaman sa desktop.

1992: mga distribution bago ang mga pamilya

Lumitaw ang MCC Interim Linux noong February 1992. Binuo ito ni Owen Le Blanc sa Manchester Computing Centre. Inilagay nito ang kernel at ang GNU (GNU's not Unix) tools sa dalawang floppy image, kasama ang menu-driven installer. Umiiral ito dahil isang buong araw ng trabaho ang kinakailangan kapag mano-manong ginagawa ang mga iyon.

Ang SLS (Softlanding Linux System), na inilabas ni Peter MacDonald noong 1992, ay nagdagdag ng X (the X Window System) at TCP/IP networking. Dahil sa SLS, nagkaroon ng ganitong kahulugan ang salitang distribution. May mga bug din ito at mabagal ang maintenance. Noong 1993, magkahiwalay na nagpasya ang dalawang tao na ayusin ito. Muling binuo ito ng isa. Muling nagsimula ang isa pa gamit ang mga nakasulat na patakaran.

Slackware, 1993: ang pinakamatandang family na patuloy na nagre-release

Inilabas ni Patrick Volkerding ang Slackware 1.00 noong 16 July 1993. Binuo ito mula sa SLS at inayos ang mga bug. Pinapanatili pa rin ito hanggang ngayon, kaya ito ang pinakamatandang Linux distribution na patuloy na umiiral.

Ang Slackware package ay isang compressed tar archive na may install script sa loob. Walang dependency resolution. Walang tumitingin kung nasa disk na ang library na kailangan ng bago mong package. Ang isang desisyong ito ang humubog sa lahat ng iba pa. Kung hindi kayang mag-resolve ng dependencies ng tool, kailangang coherent ang shipped set mula pa lamang sa pagkakabuo nito. Kaya bihira at konserbatibo ang mga release. Dumating ang Slackware 15.0 noong February 2022, anim na taon pagkatapos ng 14.2.

Maliit ang family na ito. Ang mga unang release ng SUSE noong kalagitnaan ng 1990s ay binuo mula sa Slackware, bago tumahak ang proyekto sa sarili nitong direksiyon gamit ang YaST at, kalaunan, ang RPM package format. Ang bahaging iyon ang nakalilito sa ilang tao. Gumagamit ng RPM packages ang SUSE at openSUSE, at hindi sila mga Red Hat derivative. Naglakbay ang format. Hindi ang lineage.

Debian, 1993: isang social contract at pipeline na may tatlong suite

Inanunsyo ni Ian Murdock ang Debian noong 16 August 1993, tatlong linggo pagkatapos ng Slackware at sa parehong dahilan. Pinagsasama ng pangalan ang pangalan ng kaniyang partner na si Debra at ang sarili niyang pangalan. Sinundan ito ng Debian Manifesto noong January 1994 at itinakda nito ang mga tuntunin: boluntaryo ang magme-maintain sa distribution na ito sa isang bukas na paraan, hindi isang kumpanya.

Isinulat din ng Debian ang mga tuntunin nito. Pinagtibay noong July 1997 ang Debian Social Contract at ang DFSG (Debian free software guidelines), at naging batayan ng Open Source Definition ang DFSG noong 1998. Ang isang dokumentong isinulat upang tukuyin kung ano ang maaaring mapasama sa isang distribution ay nauwi sa pagtukoy ng isang kategorya ng license para sa buong industriya. Ito rin ang dahilan kung bakit may components ang iyong sources.list: ang main ay naglalaman ng software na nakatutugon sa mga guideline, ang contrib at non-free ay naglalaman ng mga hindi nakatutugon, at idinagdag ng Debian 12 ang non-free-firmware upang makapag-install ang laptop na may wireless card nang hindi kailangang maghanap nang kung saan-saan.

Ang tooling ang isa pang mahalagang naiwan. Ang dpkg ay nag-i-install ng isang package at tumatanggi kapag may nawawala, habang ipinapakita ang dpkg: dependency problems prevent configuration of. Ang APT (advanced package tool), na naging default kasama ng Debian 2.1 noong 1999, ang layer na tumutukoy kung ano pa ang kailangang i-fetch at kung ano ang tamang pagkakasunod-sunod. Ang bawat apt command sa bawat Debian derivative ay nagmula sa gawaing iyon.

May tatlong suite ang release process at may isang tuntunin. Nag-a-upload ang maintainer sa unstable, na permanenteng may codename na sid. Inililipat ng script ang package sa testing makalipas ang humigit-kumulang 5 hanggang 10 araw, kung nag-build ito sa mga architecture ng release at walang bagong release-critical bug na lumitaw. Pagkatapos ay nagfi-freeze ang testing, nililinis ng release team ang mga natitira, at nire-release ang stable kapag sapat nang maikli ang listahan ng mga bug. Hindi ito nakabatay sa isang petsa. Kaya mukhang luma at maaasahan ang Debian stable: humihinto ang mga version number sa freeze, habang patuloy na bina-backport dito ang mga security fix.

Nakasulat din ang governance, kasama ang halal na project leader at mga general resolution na may bisa. Noong 2014, pinili ng mekanismong ito ang systemd bilang default init system, at nag-fork ang mga hindi sumang-ayon upang likhain ang Devuan, na naglabas ng unang release nito noong 2017. Kabilang sa mas malalaking descendant nito ang Ubuntu, Raspberry Pi OS, Proxmox VE, Kali at Linux Mint.

Red Hat, 1994: RPM, pagkatapos ay ang paghahati sa Fedora at RHEL

Inilabas ni Marc Ewing ang unang Red Hat Linux bandang Halloween 1994. Binili ito ng kumpanya ni Bob Young noong 1995, at binuo nilang dalawa ang unang negosyong Linux na nagbenta ng support sa halip na software. Naging public company ang Red Hat noong 11 August 1999. Tinapos ng IBM ang acquisition nito sa kumpanya noong July 2019 sa halagang humigit-kumulang 34 billion dollars. Dahil dito, ang distribution na pinagbabatayan ng certification ng karamihan sa enterprise software ay pagmamay-ari na ng IBM mula noon.

Ang pinakamahalagang teknikal na ambag nito ay ang RPM (Red Hat package manager), na isinulat nina Erik Troan at Marc Ewing para sa Red Hat Linux 2.0 noong 1995. Inilalarawan ng isang RPM ang mga dependency nito. Ginagawa ito mula sa isang spec file, isang build recipe na maaaring patakbuhin ng sinuman. Ang ikalawang katangiang ito ang nagbigay-daan sa mga independent rebuild ng enterprise product ng Red Hat.

Ang Red Hat Linux 9 noong 2003 ang huling release ng orihinal na linya. Hinati ito ng kumpanya sa dalawa: Fedora Core 1 noong November 2003 bilang mabilis na community release, at RHEL (Red Hat Enterprise Linux), na nagsimula bilang Advanced Server 2.1 noong 2002, bilang mas mabagal na bayad na release. Malinaw ang dahilan. Hindi maaaring maging sabay na lugar ng pagsubok ng mga bagong version at platform na pinapatakbo ng isang bangko nang hindi binabago sa loob ng ten years ang iisang product. Magkaugnay ang dalawang bahagi. Nagmumula ang isang RHEL major version sa isang Fedora release, pinatatatag ito, at pagkatapos ay hina-harden at hindi na binabago. Sumunod din sa parehong schedule ang package tool, mula sa yum noong 2000s patungo sa dnf bilang default ng Fedora noong 2015, habang rpm ang nasa ilalim ng dalawa.

Bakit tumigil ang CentOS sa pagiging libreng rebuild ng RHEL

Nagsimula ang CentOS noong 2004 na may simpleng gawain: kunin ang source packages na inilalabas ng Red Hat, alisin ang trademarks, i-rebuild ang mga ito, at ipamahagi nang libre ang resulta. Naging default na libreng server distribution ito sa loob ng isang dekada, at kinuha ng Red Hat ang proyekto noong 2014.

Noong 8 December 2020, inanunsyo ng Red Hat na magtatapos ang CentOS Linux 8 sa 31 December 2021, walong taon na mas maaga kaysa sa dating inanunsiyong petsa, at mananatili ang pangalan bilang CentOS Stream. Hindi rebuild ang Stream. Ito ang branch kung saan ginagawa ang mga minor release ng RHEL, kaya nauuna ito sa RHEL sa halip na nahuhuli. Para sa machine na balak mong gamitin sa loob ng maraming taon, maling direksiyon ang mauna, dahil makakatanggap ka ng mga pagbabago bago pa ito matanggap ng mga customer ng Red Hat na nagbabayad.

Dalawang rebuild ang lumitaw noong 2021. Sinimulan ni Gregory Kurtzer, na isa sa mga co-founder ng CentOS, ang Rocky Linux. Pinondohan naman ng CloudLinux ang AlmaLinux. Noong June 2023, tumigil ang Red Hat sa pag-publish ng RHEL sources saanman maliban sa CentOS Stream at customer portal nito. Nagpatuloy ang Rocky sa layuning gumawa ng mga rebuild na kapareho ng RHEL. Binago ng AlmaLinux ang layunin nito tungo sa ABI (application binary interface) compatibility. Ibig sabihin, tatakbo ang software na ginawa para sa RHEL, nang walang pangakong eksaktong magkatugma ang listahan ng mga bug sa bawat linya. Kalaunan ng taong iyon, nag-set up ang Oracle, SUSE, at CIQ ng OpenELA upang mag-publish ng mga source na pinaghahatian.

Kung CentOS pa rin ang nakalagay sa image list ng isang provider, alamin muna kung alin dito ang tinutukoy nito bago ka mag-build dito.

cat /etc/os-release

Ang NAME="CentOS Stream" ay rolling development branch na nauuna sa RHEL. Ang NAME="AlmaLinux" o NAME="Rocky Linux" ay rebuild na sumusunod dito, na may ten-year window.

Ubuntu, 2004: snapshot ng Debian unstable sa isang calendar

Inilabas ang Ubuntu 4.10 noong 20 October 2004, na pinondohan ni Mark Shuttleworth. Mechanical ang ugnayan nito sa Debian, hindi sentimental. Sa simula ng bawat cycle, ini-import ang mga package mula sa Debian unstable papunta sa bagong Ubuntu release. Tumatakbo ang mga import na ito hanggang sa Debian Import Freeze sa kalagitnaan ng cycle. Pagkatapos nito, sarili nang mga pagbabago ang dinadala ng Ubuntu. Maraming Ubuntu package ang Debian package na may dagdag na delta, at sinasabi ng changelog kung alin ang mga ito.

Ang kabilang bahagi ay ang calendar. Naglalabas ang Debian kapag handa na ito. Naglalabas ang Ubuntu tuwing April at October, at ang version number ay ang petsa: inilabas ang 24.04 noong April 2024. Ang bawat ikalawang April release ay isang LTS (long term support). Ito ang tinutukoy ng provider kapag inililista nito ang Ubuntu nang walang qualifier. Ang pagpili kung alin sa dalawa ang dapat gamitin sa server ang buong paksa ng pagpili sa pagitan ng Ubuntu LTS at interim releases, at may sarili ring procedure ang paglipat mula sa isang LTS papunta sa kasunod nito, na tinalakay sa pag-upgrade mula 24.04 papuntang 26.04.

May isang detalyeng kailangang tandaan ng mga server admin bawat taon. Hinahati ang archive ng Ubuntu sa mga component. main ay pinapanatili ng Canonical sa buong support window. Community-maintained ang universe, at iba ang security coverage na ipinapangako rito. Walang ipinapakitang pagkakaibang ito ang apt install. Isang command ang makakapagpakita nito:

apt-cache policy nginx

Ang repository line na nagtatapos sa /main ay nangangahulugang ang security team ng Canonical ang responsable sa package na iyon. Ang line na nagtatapos sa /universe ay nangangahulugang community ang responsable. Suriin ito para sa anumang service o package na nakaharap sa internet.

Arch, 2002: rolling release at ang halaga ng partial upgrade

Inilabas ni Judd Vinet ang Arch 0.1 noong 11 March 2002, kasama ang package manager na siya mismo ang sumulat, pacman, at mga build recipe na simpleng shell script. Walang versioned release ang Arch. Ang install media ay mga dated snapshot ng parehong rolling repository. Kaya ang machine na na-install noong 2019 at ina-update bawat linggo ay gumagamit ng parehong Arch gaya ng machine na na-install ngayon. Naglalaman ang AUR (Arch user repository) ng mga build recipe na ambag ng mga user. Mga recipe ang mga ito, hindi reviewed package. Kaya bahagi ng trabaho ang pagbasa sa PKGBUILD bago ito patakbuhin.

May isang failure mode ang rolling release, at bawat pagkakataon ay self-inflicted. Kapag nag-install ng isang package gamit ang pacman -Sy foo, nire-refresh nito ang package database at pagkatapos ay nag-i-install ng isang bagong binary na naka-link sa mga library na mas bago kaysa sa nasa disk. Pagkatapos, nagfa-fail ang mga program nang ganito:

error while loading shared libraries: libcrypto.so.3: cannot open shared object file: No such file or directory

Ang supported operation ay pacman -Syu, na sabay-sabay na nag-a-update ng lahat. Nagpo-post din ang project ng mga news entry na nagsasabing kailangan ang manual intervention bago ang ilang upgrade. Kapag pinatakbo ang upgrade nang hindi binabasa ang mga ito, maaaring hindi na mag-boot ang machine.

Dahil dito, hindi magandang piliin ang Arch para sa server na balak mong pabayaan. Ayos ang machine na ina-update bawat linggo. Pero kapag minsan mo lang ito in-update makalipas ang isang taon, ibibigay nito sa iyo ang lahat ng napalampas na intervention sa iisang run.

Alpine: isang maliit na distribution na pinasikat ng containers

Nagsimula ang Alpine noong bandang 2005 bilang fork ng LEAF (Linux embedded appliance framework), na nagmula naman sa Linux Router Project. Itinayo ito ni Natanael Copa para sa mga appliance, hindi para sa desktop. Pinalitan nito ang karamihan sa karaniwang userland: musl kapalit ng GNU C library, BusyBox kapalit ng GNU core utilities, OpenRC kapalit ng systemd, at apk bilang package manager. Ang Alpine 3.0 noong 2014 ang release na lumipat sa musl.

Pinasikat ito ng containers. Maliit na bahagi lamang ng laki ng Debian o Ubuntu base ang Alpine base layer. Kaya mula 2016, naging karaniwang base image ito, at maraming taong hindi kailanman nag-install ng Alpine ang gumagamit nito araw-araw.

Ang kapalit nito ay hindi glibc ang musl, at lumilitaw ang pagkakaibang ito bilang mga bug na tila walang kaugnayan. Nabibigo sa Alpine ang binary na naka-link sa glibc, at nagpapakita ito ng mensaheng naghahanap ng file na naroon na:

sh: ./myapp: not found

Nariyan ang program. Wala ang ELF interpreter nito dahil hindi kasama ang loader ng glibc. Ang Python ang isa pang karaniwang sorpresa: hindi mai-install sa musl ang mga prebuilt wheel na ginawa para sa manylinux. Kaya bumabalik ang pip sa pag-compile mula sa source at humihinto kapag walang naka-install na compiler. Naayos ito ng musllinux wheel standard noong 2021 para sa mga project na naglalabas ng ganitong mga wheel, pero hindi para sa iba.

Bilang host operating system sa isang VPS, maliit ang install ng Alpine at mabilis itong mag-update. Gayunman, inilalayo ka nito sa karaniwang setup na ipinapalagay ng karamihan sa documentation. Kailangang iangkop ang bawat guide na nagsasabing patakbuhin ang systemctl enable bilang rc-update add.

Immutable generation: atomic updates at image-based servers

Binabago ng pinakabagong branch ang update model sa halip na ang package list. Sa isang ostree-based system, read-only ang /usr. Ang isang update ay isang kumpletong bagong filesystem tree na dina-download, sine-stage, at inililipat sa susunod na reboot. Nananatili ang dating tree bilang boot entry, kaya maa-undo ang maling update sa pamamagitan ng pag-reboot gamit ang dating tree.

Dinala ng Fedora Silverblue ang modelong ito sa desktop noong 2018, at dinala naman ito ng Fedora CoreOS sa mga server noong 2019, matapos bilhin ng Red Hat ang CoreOS noong 2018. Ipinagpatuloy ng Flatcar Container Linux ang orihinal na Container Linux nang itinigil ito noong 2020. Nakakamit ng openSUSE MicroOS ang katulad na resulta sa pamamagitan ng btrfs snapshots at transactional-update. Noong 2024, nagdagdag ang Red Hat ng image-based mode sa RHEL, na binuo sa bootc. Dito, ipinapadala ang operating system bilang container image, at ina-update ang machine sa pamamagitan ng pagturo rito sa bagong tag. Pinakamalayo ang nararating ng Talos Linux dahil ganap nitong inaalis ang shell at SSH: kino-configure ang machine sa pamamagitan ng API, kaya walang kailangang pag-login-an. Ang NixOS, na unang inilabas noong 2007, ay nagmula sa ibang direksiyon. Binubuo ang buong system mula sa isang declarative configuration, at nananatiling bootable ang mga naunang generation.

Malamang na wala sa provider mo ang alinman sa mga ito bilang one-click image, dahil inaasahan nilang iko-configure ang mga ito sa unang boot gamit ang Ignition o cloud-init, sa halip na mag-edit ang administrator ng mga file sa SSH. Nakikinabang dito ang maraming magkakaparehong machine. Ito ang sitwasyon mo kapag nagma-manage ka ng maraming Linux server nang sabay-sabay at kailangan mong mapatunayan na pareho ang bawat isa sa iba.

Gaano katagal sinusuportahan ang isang release?

Ang release policy ang bahagi ng isang distribution na pinakamahabang kailangan mong pakibagayan, at inilalathala ito bilang bilang ng mga taon. Narito ang mga support window para sa 5 kasalukuyang server release.

[
  {
    "distro": "Alpine 3.x",
    "standard_years": 2,
    "extended_total_years": 2
  },
  {
    "distro": "Debian 13",
    "standard_years": 3,
    "extended_total_years": 5
  },
  {
    "distro": "Ubuntu 26.04 LTS",
    "standard_years": 5,
    "extended_total_years": 10
  },
  {
    "distro": "AlmaLinux 10",
    "standard_years": 10,
    "extended_total_years": 10
  },
  {
    "distro": "RHEL 10",
    "standard_years": 10,
    "extended_total_years": 13
  }
]

Sinusuportahan ng Alpine ang bawat 3.x branch sa loob ng 2 taon. Dahil dito, mas angkop ito sa container image na madalas mong bina-build muli kaysa sa host na hindi mo ginagalaw. Sinasaklaw ng security team ng Debian ang isang stable release nang humigit-kumulang 3 taon. Pagkatapos nito, ipinagpapatuloy ng LTS team ang suporta para sa mga karaniwang architecture hanggang humigit-kumulang 5 taon sa kabuuan. Nagbibigay ang Ubuntu LTS ng 5 taon ng suporta para sa mga package sa main. Pinahahaba ito ng Ubuntu Pro subscription hanggang 10 taon. Libre ito para sa personal na paggamit sa maliit na bilang ng mga machine. Naglalathala ang RHEL 10 ng 10 taon ng suporta. Pinahahaba ito ng paid extended life cycle support add-on hanggang 13. Tinutumbasan ng AlmaLinux 10 ang RHEL window na 10 taon nang walang subscription. Ito ang buong dahilan kung bakit umiiral ang mga rebuild na ito.

Walang row ang Arch dito dahil walang release na kailangang suportahan ang isang rolling distribution. Para sa Arch, ang mahalagang bilang ay kung gaano katagal mong maaaring iwanang hindi ginagalaw ang isang machine. Sinusukat ito sa mga linggo.

Bakit ganito ang listahan ng VPS image mo

Ang provider ay naglalabas ng mga image na hinihiling ng mga customer at awtomatikong nai-install sa hypervisor nito. Kaya halos lahat ng listahan ay nagsisimula sa Ubuntu LTS at Debian stable, nagdaragdag ng AlmaLinux o Rocky para sa mga user na ang software ay certified para sa RHEL, at inilalagay sa bandang ibaba ang Alpine, Arch, at Fedora. Kapag alam mo na kung ano ang VPS at kung paano napupunta ang image sa disk, malinaw ang pattern: pumipili ang provider ng mga operating system na maaasahan sa unattended install at mas matagal ang support kaysa sa karaniwang pananatili ng customer sa server.

Ang pagpili ay may epekto sa higit pa sa package manager. Tinutukoy nito kung anong upgrade ang patatakbuhin mo pagkalipas ng tatlong taon, at lubos na nagkakaiba ang mga iyon depende sa family. Sinusuportahan ng Debian at Ubuntu ang in-place major upgrades. Isinasagawa ng Red Hat family ang mga ito sa pamamagitan ng leapp. Walang upgrade ang Arch dahil wala itong version. Ang upgrade ng Alpine ay pag-edit sa /etc/apk/repositories at pagpapatakbo ng apk upgrade --available. Tinutukoy rin ng pagpili kung anong software ang mai-install mo nang hindi nagdaragdag ng third-party repository, kung sino ang maglalabas ng patch kapag may CVE (common vulnerabilities and exposures) entry para sa ginagamit mong software, at kung aling init system at C library ang ipagpapalagay na available ng mga gagamitin mong software sa hinaharap.

May isa pang epekto na madaling maliitin. Karamihan sa mga sagot sa internet ay ipinapalagay ang Debian family path o Red Hat family path, kaya kapag pumili ka sa labas ng dalawang ito, kakailanganin mong magsalin ng mga instruction habang ginagamit ang machine. Piliin ang family na ang release policy ay tumutugma sa dalas ng pag-aasikaso mo sa server, at panatilihin ito. Madaling palitan ang mga package na nasa ibabaw nito. Ang pagpapalit ng distribution sa ilalim ng mga iyon ay nangangahulugang muling pagbuo ng box.

FAQ

Ano ang Linux distribution family ng server ko?

Patakbuhin ang cat /etc/os-release. Tinutukoy ng field na ID ang distribution, at ng ID_LIKE ang family nito. Kaya nag-uulat ang Ubuntu machine ng ID_LIKE=debian, at ang AlmaLinux machine ng ID_LIKE="rhel centos fedora". Ang package manager ang isa pang palatandaan. Ang apt at dpkg ay nangangahulugang Debian family, ang dnf at rpm ay nangangahulugang Red Hat family, ang apk ay nangangahulugang Alpine, at ang pacman ay nangangahulugang Arch.

Libre pa bang bersyon ng RHEL ang CentOS?

Hindi. Natapos ang CentOS Linux 8, ang huling rebuild na may ganoong pangalan, noong 31 December 2021. Umabot naman ang CentOS Linux 7 sa end of life noong 30 June 2024. Ang natitirang project, ang CentOS Stream, ang branch kung saan binubuo ang RHEL minor releases. Kaya mas nauuna rito ang mga pagbabago kaysa sa RHEL, hindi nahuhuli. Ang mga libreng rebuild na pumalit sa dating papel nito ay AlmaLinux at Rocky Linux. Pareho silang may ten-year support window.

Bakit napakaluma ng mga version number ng Debian stable?

Dahil nagfi-freeze ang version number habang patuloy na dumarating ang mga fix. Nagba-backport ang Debian ng mga security patch sa inilabas nitong version sa halip na mag-import ng mas bagong upstream release. Kaya maaaring may fix na inilabas noong nakaraang linggo ang package na may bersyong 2.4.57-2+deb13u1. Ang suffix pagkatapos ng upstream version ang Debian revision, at inililista ng apt changelog <package> kung ano ang isinama rito. Mali ang magiging resulta kapag hinusgahan ang security ng Debian server batay sa mga version number nito.

Dapat ba akong gumamit ng rolling release gaya ng Arch sa isang VPS?

Oo, kung ia-update mo ito ayon sa iskedyul. Ipinapalagay ng rolling distribution na lahat ng machine ay magtatapos sa kasalukuyang package set. Kaya kapag isang package lang ang in-update gamit ang pacman -Sy foo, maaaring hindi magkatugma ang mga library at lumitaw ang mga error gaya ng cannot open shared object file. Patakbuhin nang regular ang pacman -Syu. Basahin ang project news page bago ang bawat run. Sa ganitong paraan, magiging stable ang system. Kapag hinayaan mo ito nang isang taon, magiging mapanganib ang unang upgrade.

Ano talaga ang binabago ng immutable o atomic distribution?

Binabago nito kung kailan ina-apply ang mga update at kung paano ibinabalik ang dating state. Naka-mount ang /usr bilang read-only. Ang update ay ini-stage bilang kumpletong bagong tree, at ginagawa ang switch sa reboot. Pinananatili ang dating tree bilang boot entry para sa rollback. Magkakaroon ka ng machine na alinman ay ganap nang updated o hindi pa updated, nang walang bahagyang na-apply na state. Kapalit nito, hindi ka basta makakapag-install ng software sa pamamagitan ng direktang pag-edit ng mga file. Kaya inililipat ang mga application sa containers o layered packages.