Outline sa ARM: aling build, at sino ang nagmamantini nito?

Isang tanong sa compatibility ang nilulutas ng ARM64 label at tatlong mas mahirap ang iniiwang bukas. Hindi nito sinasabi kung sino ang gumawa ng executable, sa anong source revision ito nagmula, o sino ang magpapadala ng susunod na security fix. Kapag ang isang lumang sagot sa forum ay tumuturo sa isang community build, ang mga tanong na iyon ang magpapasya kung mapagtatanggol ang pag-install. Paghiwalayin ang mga ito bago mag-download ng kahit ano.

Manager o client: piliin muna ang tamang artifact

Nagbibigay ang Outline ng manager para sa pamamahala ng mga server at client para sa pagkonekta ng mga device, at magkaibang aplikasyon ang dalawa. Kinikilala ng upstream repository ang dalawang papel at nagli-link sa kanilang sariling mga channel ng pag-install. Ang pag-install ng manager sa isang Raspberry Pi ay hindi nagbibigay sa iyo ng client para sa Pi na iyon. Nag-a-update din ang dalawang channel sa magkaibang iskedyul. Umiiral ang dalawang papel, kaya ang tanong ay alin ang dapat gampanan ng device.

Suriin ang kasalukuyang channel ng client para sa operating system na ginagamit mo. Ang generic na Linux entry ay hindi isang architecture matrix, at hindi ito pangako tungkol sa bawat board. Basahin ang download page bilang listahan ng kung ano ang umiiral, hindi listahan ng kung ano ang dapat umiiral.

Ang isang makasaysayang isyu na humihingi ng suporta sa ARM ay walang sinasabi tungkol sa kung ano ang inilalathala ngayon. Ituring itong talaan ng nakaraang puwang, hindi pahayag tungkol sa kasalukuyan. Ang channel na maaari mong i-download ang tanging ebidensyang binibilang.

Anong architecture ang talagang pinapatakbo ng naka-install na system?

Itala ang release at ang artifact na sinusuri, hindi lang ang pangalan ng board. Itugma ang executable at ang mga native na bahagi nito sa target, dahil ang 64-bit na kernel ay makakapagpatakbo ng 32-bit na userland at hindi sasabihin ng label sa kahon kung alin.

Naglalaman ang source ng client ng shared interface code at mga component na partikular sa platform. Ang muling pagbuo ng interface lamang ay hindi isang platform port, gaano man kalinis ito mag-compile. Ang mga native na bahagi ang lugar kung saan talagang lumilitaw ang architecture. Ang muling pagbuong tumatama lamang sa interface ay tatakbo at babagsak pa rin sa native na panig.

uname -m at ang package architecture ng naka-install na system ang dalawang katotohanang mahalaga dito. Basahin ang mga ito sa device, hindi sa machine na pinagbubuoan mo. Ang hindi pagtutugma sa hakbang na iyon ay nagpapawalang-bisa sa bawat susunod na paghahambing.

Nagdaragdag ang community build ng may-ari ng release

Kung walang sinusuportahang artifact ang opisyal na channel para sa iyong target, ang community build ay nagiging desisyon sa deployment kaysa pag-install. Tukuyin ang publisher, ang source revision, ang mga pagbabago mula sa upstream at ang mga tagubilin sa pagbuo.

Pagkatapos itanong kung paano nakakarating ang mga susunod na fix sa pag-install. Maaaring magmula ang mga update sa upstream, sa fork, o sa manual na muling pagbuong kailangang tandaan ng isang tao na patakbuhin. Ang ikatlong opsyon ang tahimik na tumitigil mangyari.

Ang repository na mukhang atual ay walang sinasabi tungkol sa kung anong revision ang gumawa ng binary na mayroon ka na. Ihambing ang mga tagubilin sa pagbuo sa kung ano ang iniuulat ng artifact tungkol sa sarili nito. Kung hindi magkasundo ang dalawa, ang artifact ang dapat pag-alinlanganan.

Ano ang pinatutunayan at hindi pinatutunayan ng checksum

Tinutukoy ng checksum ang partikular na mga byte. Ang checksum na inilathala ng parehong di-opisyal na builder ay hindi ginagawang upstream project ang builder na iyon, at hindi nito sinasabi kung ano ang nilalaman ng mga byte na iyon. Sinasagot nito kung dumating nang buo ang download, na isang kapaki-pakinabang ngunit makitid na tanong. Iyon ay katangian ng file, hindi ng taong naglathala nito.

Ang screenshot ng matagumpay na paglunsad ay ebidensya tungkol sa isang machine. Hindi ito review ng binary o ng update channel nito. Wala sa dalawang artifact ang kapalit ng pagbasa ng source.

Ilayo ang hindi pamilyar na build sa mga production secret hanggang masuri ang provenance at mga kinakailangang privilege. Patakbuhin muna ito sa isang throwaway environment, gamit ang sarili nitong account. Mura ito, at ginagawang test ang isang opinyon.

Magpasya kung ito ay eksperimento o appliance

Maaaring sadyang bumuo ang administrator ng nasuring source para sa sinusuportahang target at tumanggap ng responsibilidad sa mga dependency, packaging at update. Iba itong support model kaysa sa pag-install ng maintained upstream artifact. Para sa device na walang nagbabantay, piliin ang modelong kayang panatilihin ng responsableng may-ari.

Itala ang identity ng artifact, ang platform, ang resulta ng verification at ang may-ari ng update sa tabi ng deployment. Kumpleto ang desisyon kapag nagtugma ang mga ito, hindi kapag tumakbo nang isang beses ang ARM binary.