Edozein banaketatan funtzionatzen duen babeskopia aplikazio bat sortzea ez da lan erraza. Veeam Agent for Linux-ek Red Hat 6 eta Debian 6-tik, OpenSUSE 15.1 eta Ubuntu 19.04-ra arteko banaketetan funtzionatzen duela ziurtatzeko, hainbat arazo konpondu behar dituzu, batez ere software produktuak kernel-modulu bat duela kontuan hartuta.
Artikulua kongresuko hitzaldi bateko materialetan oinarrituta sortu da .
Linux ez da sistema eragile ezagunenetako bat soilik. Funtsean, plataforma bat da, eta oinarrian zerbait berezia egin dezakezu, zeurea. Horri esker, Linux-ek software osagaien multzoan desberdinak diren banaketa ugari ditu. Eta hemen arazo bat sortzen da: software-produktu batek edozein banaketatan funtziona dezan, bakoitzaren ezaugarriak kontuan hartu behar dituzu.
Paketeen kudeatzaileak. .deb vs .rpm
Has gaitezen produktua banaketa ezberdinetan banatzearen arazo nabariarekin.
Software produktuak banatzeko modurik ohikoena paketea biltegi batean jartzea da, sisteman integratutako pakete-kudeatzaileak hortik instala dezan.
Hala ere, bi pakete formatu ezagun ditugu: rpm ΠΈ deb. Horrek esan nahi du denek lagundu beharko dutela.
Deb paketeen munduan, bateragarritasun maila harrigarria da. Pakete bera instalatzen da eta berdin funtzionatzen du Debian 6 eta Ubuntu 19.04-n. Paketeak eraikitzeko eta haiekin lan egiteko prozesuaren estandarrak, Debian banaketa zaharretan ezarritakoak, garrantzitsuak izaten jarraitzen dute Linux Mint berrian eta oinarrizko sistema eragilean. Beraz, Veeam Agent for Linux-en kasuan, hardware-plataforma bakoitzeko deb pakete bat nahikoa da.
Baina rpm paketeen munduan, aldeak handiak dira. Lehenik eta behin, guztiz independenteak diren bi banatzaile daudelako, Red Hat eta SUSE, eta horietarako bateragarritasuna guztiz alferrikakoa da. Bigarrenik, banatzaile hauek horietatik banatzeko kitak dituzte. laguntza eta esperimentua. Haien arteko bateragarritasunik ere ez dago. El6, el7 eta el8 paketeak dituzte. Fedorarako pakete bereizia. SLES11 eta 12rako paketeak eta openSUSErako beste bat. Arazo nagusia mendekotasunak eta paketeen izenak dira.
Mendekotasun arazoa
Zoritxarrez, pakete berdinak askotan izen ezberdinekin amaitzen dira banaketa ezberdinetan. Jarraian veeam paketeen menpekotasunen zerrenda partziala dago.
EL7rako:
SLES 12rako:
- libblkid
- libgcc
- libstdc++
- ncurses-libs
- metxa-libs
- fitxategi-liburuak
- veeamsnap=3.0.2.1185
- libblkid1
- libgcc_s1
- libstdc++6
- libmagic1
- libfuse2
- veeamsnap-kmp=3.0.2.1185
Ondorioz, mendekotasunen zerrenda bakarra da banaketarako.
Okerragoa dena da bertsio eguneratu bat pakete zaharreko izenpean ezkutatzen hasten denean.
Adibidea:
Paketea Fedora 24-n eguneratu da madarikatuak 5. bertsiotik 6. bertsiora. Gure produktua 5. bertsioarekin eraiki zen, banaketa zaharragoekin bateragarritasuna ziurtatzeko. Fedora 5-n liburutegiaren 24. bertsio zaharra erabiltzeko, paketea erabili behar nuen ncurses-compat-libs.
Ondorioz, Fedorarako bi pakete daude, menpekotasun ezberdinekin.
Gehiago interesgarriagoa. Hurrengo banaketa eguneratzearen ondoren, paketea ncurses-compat-libs liburutegiaren 5. bertsioarekin ez dago erabilgarri. Banatzaile batentzat garestia da liburutegi zaharrak banaketaren bertsio berri batera arrastatzea. Denbora pixka bat igaro ondoren, arazoa errepikatu zen SUSE banaketetan.
Ondorioz, banaketa batzuek haien menpekotasun esplizitua kendu behar izan zuten ncurses-libs, eta konpondu produktua liburutegiko edozein bertsiorekin funtziona dezan.
Bide batez, Red Hat-en 8. bertsioan jada ez dago meta paketerik python, zahar ona aipatzen zuena 2.7. pitonoa. Badago python2 ΠΈ python3.
Pakete-kudeatzaileen alternatiba
Mendekotasunen arazoa zaharra da eta aspalditik nabaria da. Gogoratu besterik ez Mendekotasunaren infernua.
Hainbat liburutegi eta aplikazio konbinatzea, guztiak egonkor funtziona dezaten eta gatazkarik egon ez dadin - hain zuzen ere, hori da edozein Linux banatzailek konpontzen saiatzen den zeregina.
Pakete-kudeatzailea arazo hau guztiz beste modu batera konpontzen saiatzen da. snappy Canonical-etik. Ideia nagusia: aplikazioa sistema nagusitik isolatuta eta babestuta dagoen sandbox batean exekutatzen da. Aplikazio batek liburutegiak behar baditu, aplikazioarekin batera hornitzen dira.
Flatpak halaber, aplikazioak sandbox batean exekutatzeko aukera ematen du Linux Containers erabiliz. Sandbox ideia ere erabiltzen da AppImage.
Soluzio hauek edozein banaketarako pakete bat sortzeko aukera ematen dute. kasuan Flatpak aplikazioa instalatu eta abiarazi daiteke administratzaileak jakin gabe ere.
Arazo nagusia da aplikazio guztiak ezin direla sandbox batean exekutatu. Batzuek plataformarako sarbide zuzena behar dute. Ez naiz ari kernel moduluez ere, nukleoaren menpe daudenak eta sandbox kontzeptuan sartzen ez direnak.
Bigarren arazoa da Red Hat eta SUSE-ren enpresen ingurunean ezagunak diren banaketak oraindik ez dutela Snappy eta Flatpak-en laguntzarik.
Zentzu honetan, Veeam Agent for Linux ez dago erabilgarri ez piztuta .
Pakete-kudeatzaileei buruzko galdera amaitzeko, ohartu nahi nuke pakete-kudeatzaileak guztiz alde batera uzteko aukera dagoela fitxategi bitarrak eta pakete batean instalatzeko script bat konbinatuz.
Sorte horrek banaketa eta plataforma desberdinetarako pakete komun bat sortzeko aukera ematen du, instalazio prozesu interaktiboa egiteko, beharrezko pertsonalizazioa eginez. VMware-ren Linuxerako horrelako paketeak baino ez ditut topatu.
Eguneratzeko arazoa
Mendekotasun-arazo guztiak konpondu badira ere, programa desberdin exekutatu daiteke banaketa berean. Eguneratzeen kontua da.
3 eguneratze estrategia daude:
- Errazena inoiz ez eguneratzea da. Zerbitzaria konfiguratu dut eta ahaztu egin zait. Zergatik eguneratu dena funtzionatzen badu? Arazoak laguntzarekin harremanetan jartzen zaren lehen aldian hasten dira. Banaketaren sortzaileak bertsio eguneratua soilik onartzen du.
- Banatzailean fida zaitezke eta eguneratze automatikoak konfigura ditzakezu. Kasu honetan, litekeena da laguntzarako deia egitea arrakastarik gabeko eguneratze baten ondoren.
- Test-azpiegitura batean exekutatu ondoren soilik eskuz eguneratzeko aukera fidagarriena da, baina garestia eta denbora behar duena. Denek ezin dute ordaindu.
Erabiltzaile ezberdinek eguneratze estrategia desberdinak erabiltzen dituztenez, beharrezkoa da azken bertsioa eta aurretik kaleratutako guztiak onartzea. Horrek garatzeko eta probatzeko prozesua zailtzen du eta buruhausteak gehitzen dizkio laguntza taldeari.
Hardware plataforma ugari
Hardware plataforma desberdinak jatorrizko kodearen neurri handi batean berariazko arazo bat dira. Gutxienez, onartutako plataforma bakoitzerako bitarrak bildu behar dituzu.
Veeam Agent for Linux proiektuan, oraindik ezin dugu onartzen RISC hau bezalako ezer.
Ez naiz gai honi buruz zehatz-mehatz luzatuko. Arazo nagusiak soilik azalduko ditut: plataformaren araberako motak, esaterako size_t, egituraren lerrokatzea eta byteen ordena.
Lotura estatiko edo/eta dinamikoa
Baina galdera da "Nola lotu liburutegiekin - dinamikoki edo estatikoki?" eztabaidatzea merezi du.
Oro har, Linux-eko C/C++ aplikazioek lotura dinamikoa erabiltzen dute. Honek oso ondo funtzionatzen du aplikazioa banaketa zehatz baterako bereziki eraikita badago.
Zereginak hainbat banaketa fitxategi bitar batekin estaltzea bada, orduan onartutako banaketa zaharrenean zentratu behar duzu. Guretzat, hau Red Hat 6 da. Gcc 4.4 dauka, C++ 11 estandarrak ere onartzen ez duena. .
Gure proiektua gcc 6.3 erabiliz eraikitzen dugu, C++14 guztiz onartzen duena. Jakina, kasu honetan, Red Hat 6-n libstdc++ eta liburutegiak bultzatu behar dituzu zurekin. Modurik errazena haiekin estetikoki lotzea da.
Baina ai, liburutegi guztiak ezin dira estatikoki lotu.
Lehenik eta behin, sistemaren liburutegiak, esaterako libfuse, libblkid beharrezkoa da dinamikoki lotzea nukleoarekin eta bere moduluekin bateragarritasuna ziurtatzeko.
Bigarrenik, sotiltasun bat dago lizentziekin.
GPL lizentziak, funtsean, liburutegiak kode irekiarekin soilik lotzeko aukera ematen du. MIT eta BSD-ek lotura estatikoak ahalbidetzen dituzte eta liburutegiak proiektu batean sartzeko aukera ematen dute. Baina LGPLk ez dirudi lotura estatikoarekin kontraesanean dagoenik, baina lotzeko beharrezkoak diren fitxategiak partekatzea eskatzen du.
Orokorrean, esteka dinamikoak erabiltzeak ezer eman behar izatea eragotziko du.
C/C++ aplikazioak eraikitzea
Plataforma eta banaketa ezberdinetarako C/C++ aplikazioak eraikitzeko, nahikoa da gcc-ren bertsio egoki bat hautatzea edo eraikitzea eta arkitektura zehatzetarako zehar-konpiladoreak erabiltzea eta liburutegien multzo osoa muntatzea. Lan hau nahiko bideragarria da, baina nahiko kezkagarria. Eta ez dago bermatzen hautatutako konpilatzaileak eta liburutegiak bertsio erabilgarri bat emango dutenik.
Abantaila nabaria: azpiegitura asko errazten da, eraikuntza prozesu osoa makina batean osa baitaiteke. Horrez gain, nahikoa da arkitektura baterako bitar multzo bat biltzea eta banaketa desberdinetarako paketeetan paketatu ditzakezu. Horrela eraikitzen dira veeam paketeak Veeam Agent for Linuxerako.
Aukera honen aurrean, eraikitzeko baserri bat presta dezakezu, hau da, hainbat makina muntatzeko. Horrelako makina bakoitzak aplikazioen konpilazioa eta paketeen muntaia emango du banaketa eta arkitektura zehatz baterako. Kasu honetan, konpilazioa banatzaileak prestatutako bitartekoak erabiliz egiten da. Hau da, konpilatzailea prestatzeko eta liburutegiak hautatzeko fasea ezabatzen da. Horrez gain, eraikuntza prozesua erraz paralelizatu daiteke.
Hala ere, ikuspegi honek alde txarra du: arkitektura bereko banaketa bakoitzeko, zure fitxategi bitar multzoa bildu beharko duzu. Beste desabantaila bat da makina kopuru handia mantendu behar dela eta diskoko espazio eta RAM kopuru handia esleitu behar dela.
Honela konpilatzen dira veeamsnap kernel moduluaren KMOD paketeak Red Hat banaketetarako.
Ireki Eraikitze Zerbitzua
SUSEko lankideak erdibide batzuk ezartzen saiatu ziren aplikazioak biltzeko eta paketeak muntatzeko zerbitzu berezi baten moduan - .
Funtsean, makina birtual bat sortzen duen hipervisor bat da, bertan beharrezko pakete guztiak instalatzen ditu, aplikazioa konpilatzen du eta ingurune isolatu honetan paketea eraikitzen du, eta ondoren makina birtuala askatzen da.
OpenBuildService-n inplementatutako programatzaileak zehaztuko du zenbat makina birtual abiarazi ditzakeen paketeak eraikitzeko abiadura optimorako. Sinadura-mekanismo integratuak paketeak sinatuko ditu eta barneko biltegira igoko ditu. Bertsioen kontrol sistema integratuak aldaketen eta eraikitzeen historia gordeko du. Zure iturriak sistema honetara gehitzea besterik ez da geratzen. Ez duzu zerbitzaria zuk zeuk konfiguratu beharrik; irekitako bat erabil dezakezu.
Bada, ordea, arazo bat: halako uzta-biltzaile bat zaila da egungo azpiegituretan sartzea. Adibidez, bertsio-kontrola ez da beharrezkoa; dagoeneko badugu gurea iturburu-kodeetarako. Gure sinadura mekanismoa ezberdina da: zerbitzari berezi bat erabiltzen dugu. Biltegi bat ere ez da beharrezkoa.
Gainera, beste banaketa batzuen laguntza - Red Hat adibidez - nahiko gaizki inplementatzen da, eta hori ulergarria da.
Zerbitzu horren abantaila SUSE banaketaren hurrengo bertsiorako laguntza azkarra da. Argitalpenaren iragarpen ofiziala baino lehen, muntatzeko beharrezkoak diren paketeak biltegi publiko batean argitaratzen dira. Berri bat agertzen da OpenBuildService-n erabilgarri dauden banaketen zerrendan. Laukia markatzen dugu eta eraikuntza-planari gehitzen zaio. Horrela, banaketaren bertsio berri bat gehitzea ia klik bakarrean egiten da.
Gure azpiegituran, OpenBuildService erabiliz, SUSE banaketetarako veeamsnap kernel moduluaren KMP pakete guztiak muntatzen dira.
Ondoren, nukleoaren moduluei buruzko gai espezifikoak aztertu nahi nituzke.
nukleoa ABI
Historikoki, Linux kernel moduluak iturri moduan banatu dira. Kontua da nukleoaren sortzaileek ez dutela kernelaren moduluetarako API egonkor bat babesteko kezkaz zamatzen, eta batez ere maila bitarrean, gehiago kABI deitzen dena.
Banilla kernel baterako modulu bat eraikitzeko, kernel jakin honen goiburuak behar dituzu zalantzarik gabe, eta kernel honetan bakarrik funtzionatuko du.
DKMS-k nukleoa eguneratzean moduluak eraikitzeko prozesua automatizatzeko aukera ematen du. Ondorioz, Debian biltegiko erabiltzaileek (eta haren ahaide asko) nukleoaren moduluak erabiltzen dituzte banatzailearen biltegitik edo DKMS erabiliz iturburutik konpilatuta.
Dena den, egoera hau ez da bereziki egokitzen Enterprise segmentuari. Kode jabedunen banatzaileek produktua konpilatutako bitar gisa banatu nahi dute.
Administratzaileek ez dituzte garapen-tresnak ekoizpen-zerbitzarietan gorde nahi segurtasun arrazoiengatik. Red Hat eta SUSE bezalako Enterprise Linux banatzaileek kABI egonkorra onartzen zutela erabaki zuten erabiltzaileentzat. Emaitza Red Hat-erako KMOD paketeak eta SUSErako KMP paketeak izan ziren.
Irtenbide honen funtsa nahiko erraza da. Banaketaren bertsio zehatz baterako, nukleoaren APIa izoztuta dago. Banatzaileak dio nukleoa erabiltzen duela, adibidez, 3.10, eta nukleoaren interfazeei eragiten ez dieten zuzenketak eta hobekuntzak soilik egiten dituela, eta lehen nukleorako bildutako moduluak ondorengo guztietarako erabil daitezke birkonpilatu gabe.
Red Hat-ek kABI bateragarritasuna aldarrikatzen du banaketarako bere bizi-ziklo osoan. Hau da, rhel 6.0rako muntatutako moduluak (2010eko azaroan kaleratzea) 6.10 bertsioan ere funtzionatu beharko luke (2018ko ekainean kaleratzea). Eta ia 8 urte dira. Jakina, zeregin hau nahiko zaila da.
kABI bateragarritasun arazoengatik veeamsnap moduluak funtzionatzeari utzi dion hainbat kasu erregistratu ditugu.
RHEL 7.0-rako konpilatutako veeamsnap modulua RHEL 7.5-eko nukleoarekin bateraezina izan ondoren, baina kargatu eta zerbitzaria huts egingo zuela bermatuta zegoen, kABI bateragarritasuna erabat utzi genuen RHEL 7rako.
Gaur egun, RHEL 7rako KMOD paketeak bertsio bakoitzeko muntaia bat eta modulua kargatzen duen script bat ditu.
SUSEk arreta handiagoz heldu zion kABI bateragarritasunari. KABI bateragarritasuna zerbitzu pakete baten barruan bakarrik eskaintzen dute.
Adibidez, SLES 12 kaleratzea 2014ko irailean egin zen. Eta SLES 12 SP1 2015eko abenduan zegoen jada, hau da, urtebete baino pixka bat gehiago igaro da. Bi bertsioek 3.12 nukleoa erabiltzen badute ere, kABI bateraezinak dira. Jakina, kABI bateragarritasuna urtebetez mantentzea askoz errazagoa da. Nukleoaren urteko eguneratze-zikloak ez die arazorik sortu behar moduluen sortzaileei.
SUSE politika honen ondorioz, ez dugu kABI bateragarritasunarekin arazo bakar bat ere erregistratu gure veeamsnap moduluan. Egia da, SUSErako pakete kopurua ia magnitude ordena handiagoa da.
Adabakiak eta backports
Banatzaileak kABI bateragarritasuna eta nukleoaren egonkortasuna ziurtatzen saiatzen diren arren, errendimendua hobetzen eta nukleo egonkor honen akatsak kentzen ere saiatzen dira.
Aldi berean, beren "akatsen gainean" lan egiteaz gain, Linux kernel enpresako garatzaileek bainilla nukleoan aldaketak egiten dituzte eta beren "egonkor" batera transferitzen dituzte.
Batzuetan, horrek berriak sortzen ditu .
Red Hat 6-ren azken bertsioan, akats bat egin zen eguneratze txikietako batean. Izan ere, veeamsnap moduluak sistemaren hutsegitea bermatuta zegoela ekarri zuen argazkia kaleratu zenean. Eguneratze aurretik eta ondoren nukleoaren iturriak alderatu ondoren, backport-a erruduna zela jakin genuen. Antzeko konponketa bat egin zen vanilla kernel 4.19 bertsioan. Konponketa honek bainila nukleoan ondo funtzionatu zuela da, baina 2.6.32 "egonkorra"ra transferitzean, arazo bat sortu zen spinlock-arekin.
Noski, denek beti izaten dituzte akatsak, baina merezi izan al zuen kodea 4.19tik 2.6.32ra arrastatzeak, egonkortasuna arriskuan jarriz?... Ez nago ziur...
Okerrena da marketina "egonkortasunaren" eta "modernizazioaren" arteko tirabiran parte hartzen duenean. Marketin sailak eguneratutako banaketaren muina egonkorra izan dadin behar du, batetik, eta, aldi berean, errendimendu hobea izateko eta ezaugarri berriak izateko. Horrek konpromiso bitxiak dakartza.
SLES 4.4 SP12-tik 3 kernelean modulu bat eraikitzen saiatu nintzenean, harritu egin nintzen vanilla 4.8-ren funtzionaltasuna aurkitzea. Nire ustez, SLES 4.4 SP12-ko 3 kernelaren bloke I/O inplementazioa 4.8 kernelaren antzekoagoa da SLES4.4 SP12-ren 2 kernel egonkorraren aurreko bertsioa baino. Ezin dut epaitu zein ehuneko kode transferitu zen nukleotik 4.8 SLES 4.4ra SP3rako, baina ezin dut nukleoari 4.4 egonkor bera deitu ere egin.
Honen gauzarik desatseginena zera da: nukleo ezberdinetan berdin funtzionatuko lukeen modulu bat idaztean, jada ezin zarela nukleoaren bertsioan fidatu. Banaketa ere kontuan hartu behar da. Ona da batzuetan funtzionalitate berriekin batera agertzen den definizio batean parte hartzea, baina aukera hau ez da beti agertzen.
Ondorioz, kodea konpilazio baldintza bitxiekin hazten da.
Dokumentatutako nukleoaren APIa aldatzen duten adabakiak ere badaude.
Banaketarekin egin nuen topo 5.16 eta oso harrituta geratu zen nukleoaren bertsio honetako lookup_bdev deiak sarrerako parametroen zerrenda aldatu zuela ikustean.
Elkartzeko, makefilera lookup_bdev funtzioak maskara parametrorik duen egiaztatzen duen script bat gehitu behar izan nuen.
Nukleoko moduluak sinatzea
Baina itzul gaitezen pakete banaketaren gaira.
kABI egonkorraren abantailetako bat nukleoaren moduluak fitxategi bitar gisa sinatu daitezkeela da. Kasu honetan, garatzaileak ziur egon daiteke modulua ez dela ustekabean kaltetu edo nahita aldatu. Hau modinfo komandoarekin egiaztatu dezakezu.
Red Hat eta SUSE banaketak moduluaren sinadura egiaztatzeko eta kargatzeko aukera ematen dizu dagokion ziurtagiria sisteman erregistratuta badago. Ziurtagiria modulua sinatzen den gako publikoa da. Pakete bereizi gisa banatzen dugu.
Hemen arazoa da ziurtagiriak nukleoan eraiki daitezkeela (banatzaileek erabiltzen dituzte) edo EFI memoria ez-hegazkorran idatzi behar direla utilitate baten bidez. mokutil. Erabilgarritasuna mokutil Ziurtagiri bat instalatzean, sistema berrabiarazi behar duzu eta, sistema eragilearen nukleoa kargatu aurretik ere, administratzaileari ziurtagiri berri bat kargatzeko baimena eskatzen dio.
Hortaz, ziurtagiri bat gehitzeak sisteman administratzaile fisikoa sarbidea behar du. Makina hodeian edo, besterik gabe, urruneko zerbitzari-gela batean badago eta sarbidea sarearen bidez soilik bada (adibidez, ssh bidez), orduan ezinezkoa izango da ziurtagiri bat gehitzea.
EFI makina birtualetan
Ia plaka-fabrikatzaile guztiek EFI aspalditik onartzen duten arren, sistema bat instalatzerakoan, baliteke administratzaileak ez pentsatzea EFIren beharraz, eta desgaitu egin daiteke.
Hipervisor guztiek ez dute EFI onartzen. VMWare vSphere-k EFI onartzen du 5. bertsiotik hasita.
Microsoft Hyper-V-ek EFI laguntza ere lortu zuen Hyper-V-rekin Windows Server 2012R2rako.
Hala ere, konfigurazio lehenetsian funtzionalitate hori desgaituta dago Linux makinentzat, hau da, ezin da ziurtagiria instalatu.
vSphere 6.5-en, ezarri aukera Itsasontzi segurua Flash bidez exekutatzen den web interfazearen bertsio zaharrean soilik posible da. Web UI HTML-5-en oraindik oso atzean dago.
Banaketa esperimentalak
Eta azkenik, kontuan izan dezagun laguntza ofizialik gabeko banaketa eta banaketa esperimentalen gaia. Alde batetik, erakunde serioen zerbitzarietan nekez aurki daitezke horrelako banaketak. Ez dago laguntza ofizialik horrelako banaketak egiteko. Beraz, eman horiek. Produktua ezin da halako banaketa batean onartu.
Hala ere, halako banaketak soluzio esperimental berriak probatzeko plataforma eroso bihurtzen dira. Adibidez, Debian-en Fedora, OpenSUSE Tumbleweed edo Unstable bertsioak. Nahiko egonkorrak dira. Beti dituzte programen bertsio berriak eta beti kernel berri bat. Urtebete barru, funtzionalitate esperimental hau RHEL, SLES edo Ubuntu eguneratu batean amai daiteke.
Beraz, zerbaitek banaketa esperimental batean funtzionatzen ez badu, arazoa asmatzeko eta konpontzeko arrazoia da. Prestatuta egon behar duzu funtzionalitate hori laster erabiltzaileen ekoizpen-zerbitzarietan agertuko dela.
3.0 bertsiorako ofizialki onartzen diren banaketen egungo zerrenda azter dezakezu . Baina gure produktuak lan egin dezakeen banaketaren benetako zerrenda askoz zabalagoa da.
Pertsonalki, Elbrus OSrekin egindako esperimentua interesatzen zitzaidan. Veeam paketea amaitu ondoren, gure produktua instalatu eta funtzionatzen zuen. Esperimentu honi buruz idatzi nuen HabrΓ©-n .
Beno, banaketa berrietarako laguntzak jarraitzen du. 4.0 bertsioa noiz aterako zain gaude. Beta agertzear dago, beraz, adi egon !
Iturria: www.habr.com