Kasaysayan ng Linux distributions at package managers

Ano talaga ang isang Linux distribution

Nagsisimula ang kasaysayan ng Linux distributions sa isang kakulangan: walang nagagawa ang Linux kernel nang mag-isa na magagamit ng tao. Nagbo-boot ito at hinahanap ang hardware. Pagkatapos, humihinto ito. Kailangang magdagdag ang isang tao 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 kabuuan ng mga pagpipiliang iyon, pati ang grupo ng mga taong nananatiling nangangalaga rito.

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

• Isang kernel, sa bersyong pinili ng project, kasama ang mga patch at driver na idinagdag nito.
• Isang userland: ang C library, shell, init system, at 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 nasira ang isang package.

Ang kernel ang bahaging pinagsasaluhan, kaya mas magkakalapit ang dalawang Linux distribution sa isa't isa kaysa sa alinman sa mga ito sa ibang Unix. Mahalagang tandaan ito kapag inihahambing ang Linux at FreeBSD bilang mga server platform, kung saan isang project ang bumubuo sa kernel at base userland at sabay na nire-release ang mga ito. Sa Linux, nagmumula ang mga bahaging ito sa magkakahiwalay na upstream, at ang distribution ang nagtitiyak na magkakatugma ang mga ito.

Kasaysayan ng mga Linux distribution sa tatlong pamilya

Nagsimula noong 1993 at 1994 ang tatlong proyekto na naging mga pamilya: Slackware, Debian, at Red Hat. Halos bawat image sa VPS control panel ngayon ay isa sa mga ito o descendant ng isa sa mga ito. Minamana ng descendant ang package format, file layout, at karaniwang release practices. Kaya kahit wala na ang dating branding, Debian pa rin ang pakiramdam ng isang Debian derivative.

Nararapat sa mga independent ang sarili nilang linya dahil wala silang pinagkuhanang proyekto. Sariling package manager at sariling rules ang isinulat ng Arch, Gentoo, Alpine, NixOS, at Void. Dalawa sa mga ito, ang Arch at Alpine, ay napabilang din sa image list ng provider mo, para sa mga dahilang walang kinalaman sa desktop.

1992: ang mga distribution bago ang mga pamilya

Lumabas ang MCC Interim Linux noong Pebrero 1992. Inihanda ito ni Owen Le Blanc sa Manchester Computing Centre. Inilagay nito ang kernel at mga tool ng GNU (GNU's not Unix) sa dalawang floppy image, kasama ang menu-driven installer. Ginawa ito dahil umaabot ng isang araw ang manu-manong paggawa nito.

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, naging ganito ang kahulugan ng salitang distribution. Marami rin itong bug at mabagal ang maintenance. Noong 1993, magkahiwalay na nagpasya ang dalawang tao na ayusin ito. Muling binuo ito ng isa. Ang isa naman ay nagsimula ulit gamit ang nakasulat na mga panuntunan.

Slackware, 1993: ang pinakamatandang pamilya na patuloy na naglalabas ng release

Inilabas ni Patrick Volkerding ang Slackware 1.00 noong 16 July 1993. Binuo ito mula sa SLS at inayos ang mga bug. Patuloy pa rin itong pinananatili, 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 tumitiyak na nasa disk na ang library na kailangan ng bago mong package. Ang iisang desisyong ito ang humubog sa lahat ng iba pa. Kung hindi magre-resolve ng dependencies ang tool, kailangang coherent na agad ang set na inilalabas. Dahil dito, bihira at konserbatibo ang mga release. Dumating ang Slackware 15.0 noong February 2022, anim na taon pagkatapos ng 14.2.

Maliit ang pamilyang ito. Ang mga pinakaunang release ng SUSE noong kalagitnaan ng 1990s ay binuo sa Slackware, bago tumahak ang proyekto sa sarili nitong direksiyon gamit ang YaST at, kalaunan, ang RPM package format. Dito nalilito ang ilang tao. Gumagamit ang SUSE at openSUSE ng RPM packages, at hindi sila derivatives ng Red Hat. Kumalat 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. Pinagsama sa pangalan nito 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: pananatilihin nang bukas ng mga volunteer ang distribution na ito, hindi ng isang kumpanya.

Isinulat din ng Debian ang mga tuntuning ito. 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 dokumentong isinulat upang tukuyin kung ano ang kabilang sa isang distribution ay nauwi sa pagbuo ng kategorya ng mga lisensya para sa buong industriya. Ito rin ang dahilan kung bakit may components ang iyong sources.list: naglalaman ang main ng software na sumusunod sa mga guideline, naglalaman ang contrib at non-free ng hindi sumusunod, at idinagdag ng Debian 12 ang non-free-firmware upang makapag-install ang laptop na may wireless card nang hindi kinakailangang maghanap nang hiwa-hiwalay ng mga package.

Ang tooling ang isa pang mahalagang pamana. Nag-i-install ang dpkg ng isang package at tumitigil 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 kunin at kung anong pagkakasunod-sunod. Ang bawat command na apt sa bawat Debian derivative ay nagmula sa gawaing iyon.

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

Nakasulat din ang governance, kasama ang halal na project leader at mga binding general resolution. 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. Hindi ang Debian ang unang distribution na gumawa ng pagbabagong iyon at hindi rin ito ang huli. Ang mga dahilan kung bakit patuloy itong nangyayari, pati ang mga pagtutol na napatunayang tama, ay inilahad sa salaysay kung paano pinalitan ng systemd ang SysV init. Ang mas malalaking descendant nito ay Ubuntu, Raspberry Pi OS, Proxmox VE, Kali at Linux Mint.

Red Hat, 1994: RPM, pagkatapos ay paghihiwalay 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 nagbebenta ng support sa halip na software. Naging public company ang Red Hat noong 11 August 1999. Isinara ng IBM ang acquisition nito sa kumpanya noong July 2019 sa halagang humigit-kumulang 34 billion dollars. Dahil dito, ang distribution na pinakamaraming enterprise software ang ginagawang certification base ay pagmamay-ari na ng IBM mula noon.

Ang pangmatagalang teknikal na ambag nito ay RPM (Red Hat package manager), na isinulat nina Erik Troan at Marc Ewing para sa Red Hat Linux 2.0 noong 1995. Idinedeklara ng 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 kalaunan.

Ang Red Hat Linux 9 noong 2003 ang huli sa 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 mabagal at bayad na release. Malinaw ang dahilan. Hindi maaaring maging sabay ang isang produkto bilang lugar para subukan ang mga bagong version at bilang platform na pinapatakbo ng bangko nang hindi binabago sa loob ng sampung taon. Magkaugnay ang dalawang bahagi. Nagmumula ang isang RHEL major version sa isang Fedora release, pinapastable ito, at pagkatapos ay ni-freeze. Sumunod din ang package tool sa parehong iskedyul, mula sa yum noong 2000s tungo sa dnf bilang default ng Fedora noong 2015, habang nasa ilalim ng dalawa ang rpm.

Bakit hindi na libreng RHEL rebuild ang CentOS

Nagsimula ang CentOS noong 2004 na may simpleng layunin: kunin ang source packages na inilabas 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 inilathalang petsa. Inanunsyo rin nitong magpapatuloy ang pangalan bilang CentOS Stream. Hindi rebuild ang Stream. Ito ang branch kung saan kinukuha ang minor release ng RHEL. Dahil dito, nauuna ito sa RHEL sa halip na nahuhuli. Para sa machine na balak mong gamitin nang maraming taon, maling direksyon ang pagiging nauuna. Makakatanggap ka ng mga pagbabago bago pa man matanggap ng mga nagbabayad na customer ng Red Hat.

Dalawang rebuild ang lumitaw noong 2021. Sinimulan ni Gregory Kurtzer ang Rocky Linux. Siya ang isa sa mga co-founder ng CentOS. Pinondohan naman ng CloudLinux ang AlmaLinux. Noong June 2023, tumigil ang Red Hat sa pag-publish ng RHEL sources sa lahat ng lugar maliban sa CentOS Stream at customer portal nito. Patuloy na itinaguyod ng Rocky ang mga rebuild na kapareho ng orihinal. Binago naman ng AlmaLinux ang layunin nito tungo sa ABI (application binary interface) compatibility. Ibig sabihin, tatakbo ang software na binuo para sa RHEL, pero walang pangakong eksaktong magkatugma ang listahan ng bugs sa bawat linya. Itinatag naman ng Oracle, SUSE, at CIQ ang OpenELA sa huling bahagi ng taong iyon upang mag-publish ng shared sources. Sinusuri sa mas mahabang salaysay tungkol sa Red Hat, CentOS, Rocky, at AlmaLinux ang buong pagkakasunod-sunod, mula sa paghihiwalay noong 2003 hanggang sa pagbabago sa source noong 2023, pati ang kasalukuyang ipinapangako ng bawat rebuild.

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

cat /etc/os-release

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

Ubuntu, 2004: snapshot ng Debian unstable ayon sa iskedyul

Inilabas ang Ubuntu 4.10 noong 20 October 2004, na pinondohan ni Mark Shuttleworth. Ang ugnayan nito sa Debian ay mekanikal, 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 ng Ubuntu ang ipinapatupad. Maraming Ubuntu package ang Debian package na may delta, at sinasabi ng changelog kung alin ang mga ito.

Ang kabilang bahagi ay ang iskedyul. Nagre-release ang Debian kapag handa na ito. Nagre-release ang Ubuntu tuwing April at October, at ang version number ay ang petsa: inilabas ang 24.04 noong April 2024. Ang bawat ikalawang release tuwing April ay isang LTS (long term support). Ito ang tinutukoy ng provider kapag naglilista ito ng 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 saklaw sa pag-upgrade mula 24.04 papuntang 26.04.

May isang detalyeng taun-taong kailangang tandaan ng mga server admin. Hinahati ang Ubuntu archive sa mga component. Ang main ay pinapanatili ng Canonical sa buong support window. Community-maintained ang universe, at iba ang saklaw ng security support nito. Walang ipinapakitang pagkakaiba ang apt install. Ipinapakita ito ng isang command:

apt-cache policy nginx

Ang repository line na nagtatapos sa /main ay nangangahulugang nasa security team ng Canonical ang responsibilidad para sa package na iyon. Ang line na nagtatapos sa /universe ay nangangahulugang community ang may responsibilidad. Suriin ito para sa anumang serbisyong nakaharap sa internet.

Arch, 2002: rolling releases at ang kapalit 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 mga plain shell script. Walang versioned release ang Arch. Ang install media ay mga snapshot na may petsa 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. Nasa AUR (Arch user repository) ang mga build recipe na ambag ng mga user. Mga recipe ang mga ito, hindi mga package na nasuri na. Kaya bahagi ng trabaho ang pagbasa sa PKGBUILD bago ito patakbuhin.

May isang failure mode ang rolling model, at sariling gawa ito sa bawat pagkakataon. 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 mga 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 suportadong 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 ng 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 kung isang beses mo lang ito i-update makalipas ang isang taon, haharapin mo sa iisang run ang lahat ng intervention na nalaktawan.

Alpine: ang maliit na distribution na pinasikat ng mga container

Nagsimula ang Alpine noong humigit-kumulang 2005 bilang fork ng LEAF (Linux embedded appliance framework), na nagmula naman sa Linux Router Project. Binuo ito ni Natanael Copa para sa mga appliance, hindi para sa mga 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 mga container. 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 nagpapatakbo nito araw-araw.

Ang kapalit nito ay hindi glibc ang musl, at lumilitaw ang pagkakaibang ito bilang mga bug na mukhang walang kaugnayan. Nabibigo sa Alpine ang binary na naka-link sa glibc, na may mensaheng nagtutulak sa mga user na hanapin ang file na naroon na:

sh: ./myapp: not found

Umiiral ang program. Wala ang ELF interpreter nito dahil hindi naka-install ang loader ng glibc. Ang Python ang isa pang karaniwang pinagmumulan ng 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. Nalutas ito ng musllinux wheel standard noong 2021 para sa mga project na naglalathala ng mga wheel na iyon, ngunit hindi para sa iba.

Bilang host operating system sa isang VPS, mabilis i-install at mabilis i-update ang Alpine. Ngunit inilalayo ka nito sa karaniwang landas na ipinapalagay ng karamihan sa documentation. Kailangang isalin ang bawat guide na nagsasabing patakbuhin ang systemctl enable tungo sa rc-update add.

Ang immutable generation: atomic updates at image-based na mga server

Binabago ng pinakabagong branch ang modelo ng pag-update, hindi ang listahan ng package. Sa ostree-based system, read-only ang /usr. Ang update ay isang kumpletong bagong filesystem tree na dina-download, sine-stage, at inililipat sa susunod na reboot. Iniiwan ang dating tree bilang boot entry, kaya maaaring ibalik ang isang 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 ihinto ito noong 2020. Nakakamit ng openSUSE MicroOS ang katulad na resulta gamit ang btrfs snapshots at transactional-update. Noong 2024, nagdagdag ang Red Hat ng image-based mode sa RHEL, na binuo sa bootc. Sa mode na ito, ipinapadala ang operating system bilang container image at ina-update ang machine sa pamamagitan ng pagturo nito sa bagong tag. Mas malayo ang nararating ng Talos Linux: tuluyan 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 gumagamit ng ibang paraan. Binubuo ang buong system mula sa isang declarative configuration, at nananatiling puwedeng i-boot ang mga naunang generation.

Malamang na wala sa iyong provider 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 i-edit ng administrator ang mga file sa pamamagitan ng SSH. Pinakamalaki ang pakinabang ng mga ito kapag maraming magkakaparehong machine ang pinamamahalaan. Iyan ang sitwasyon kapag ikaw ay namamahala ng ilang Linux server nang sabay-sabay at kailangan mong mapatunayang pareho ang bawat isa sa iba.

Gaano katagal sinusuportahan ang isang release?

Ang release policy ang bahagi ng distribution na pinakamahaba mong ginagamit, 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. Kaya mas angkop ito sa container image na madalas mong nire-rebuild kaysa sa host na matagal mong hindi ginagalaw. Sinasaklaw ng security team ng Debian ang isang stable release nang humigit-kumulang 3 taon. Pagkatapos, 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. Pinapahaba ito ng Ubuntu Pro subscription sa 10 taon, at libre ito para sa personal na paggamit sa maliit na bilang ng mga machine. Naglalathala ang RHEL 10 ng 10 taon ng suporta. Pinapahaba ito ng bayad na extended life cycle support add-on hanggang 13 taon. Tinutumbasan ng AlmaLinux 10 ang RHEL window na 10 taon nang walang subscription. Iyan ang buong dahilan kung bakit umiiral ang mga rebuild.

Walang row ang Arch dito dahil walang release na kailangang suportahan ang 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 hitsura ng listahan ng VPS images mo

Inilalabas ng provider ang 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, idinadagdag ang AlmaLinux o Rocky para sa mga gumagamit 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 maaasahang mai-install nang walang user intervention at mas matagal na suportado kaysa sa karaniwang tagal ng paggamit ng customer sa server.

Ang pagpili ay hindi lang tungkol sa package manager. Tinutukoy din nito ang upgrade na gagawin mo pagkalipas ng tatlong taon, at lubos na magkakaiba ang mga prosesong ito depende sa distribution family. Sinusuportahan ng Debian at Ubuntu ang major upgrade habang tumatakbo ang kasalukuyang installation. Isinasagawa naman ito ng Red Hat family gamit ang leapp. Walang upgrade ang Arch dahil wala itong version. Ang proseso sa Alpine ay ang pag-edit ng /etc/apk/repositories at pagpapatakbo ng apk upgrade --available. Tinutukoy rin ng pagpili kung aling 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 isang component na ginagamit mo, at kung aling init system at C library ang ipagpapalagay ng future software na naroon.

May isa pang epekto na madaling maliitin. Ipinapalagay ng karamihan sa mga sagot sa internet na Debian family path o Red Hat family path ang ginagamit. Kaya kapag pumili ka sa labas ng dalawang ito, kailangan mong isalin ang mga instruction sa buong panahon ng paggamit ng machine. Piliin ang family na ang release policy ay tugma sa dalas ng pag-aasikaso mo sa server, at manatili rito. Madaling baguhin ang mga package na nakapatong dito. Ang pagpapalit ng distribution sa ilalim ng mga package ay nangangahulugang kailangan mong i-rebuild ang box.

FAQ

Saang Linux distribution family kabilang ang server ko?

Patakbuhin ang cat /etc/os-release. Tinutukoy ng field na ID ang distribution, at tinutukoy naman ng ID_LIKE ang family nito. Kaya mag-uulat ang isang Ubuntu machine ng ID_LIKE=debian, at ang isang AlmaLinux machine ay mag-uulat 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.

Libreng bersyon pa rin ba ng RHEL ang CentOS?

Hindi. Natapos ang CentOS Linux 8, ang huling rebuild na gumamit ng pangalang iyon, 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 mga minor release ng RHEL. Kaya nauuna rito ang mga pagbabago bago mapunta sa RHEL, sa halip na mahuli rito. Ang mga libreng rebuild na pumalit sa dating role nito ay AlmaLinux at Rocky Linux, na parehong may ten-year window.

Bakit napakaluma ng mga version number sa Debian stable?

Dahil nagfi-freeze ang version number habang patuloy na dumarating ang mga fix. Nagba-backport ang Debian ng mga security patch sa version na inilabas nito sa halip na mag-import ng mas bagong upstream release. Kaya maaaring may fix na inilathala noong nakaraang linggo ang package na may 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. Palaging mali ang magiging sagot kung huhusgahan 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 lamang kung regular mo itong ia-update ayon sa iskedyul. Ipinapalagay ng rolling distribution na lahat ng machine ay mapupunta sa kasalukuyang package set. Kaya kapag nag-update ka ng isang package 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 pag-update, at magiging stable ang system. Kung pababayaan mo ito nang isang taon, magiging mapanganib ang unang upgrade.

Ano talaga ang binabago ng immutable o atomic distribution?

Binabago nito kung kailan inilalapat ang mga update at kung paano ibinabalik ang dating estado. Naka-mount ang /usr bilang read-only. Ipinaprepare ang update bilang isang kumpletong bagong tree, at isinasagawa ang paglipat sa reboot. Pinananatili ang dating tree bilang boot entry para sa rollback. Makakakuha ka ng machine na alinman ay ganap nang updated o hindi pa updated, nang walang bahagyang nailapat na estado. Isinusuko mo ang pag-install ng software sa pamamagitan ng direktang pag-edit ng mga file. Kaya inililipat ang mga application sa containers o sa layered packages.