Krei rezervan aplikaĵon, kiu funkcias en iu ajn distribuo, ne estas facila tasko. Por certigi, ke Veeam Agent por Linukso funkcias ĉe distribuoj de Red Hat 6 kaj Debian 6, ĝis OpenSUSE 15.1 kaj Ubuntu 19.04, vi devas solvi gamon da problemoj, precipe konsiderante ke la programaro inkluzivas kernan modulon.
La artikolo estis kreita surbaze de materialoj el parolado en la konferenco .
Linukso ne estas nur unu el la plej popularaj operaciumoj. Esence, ĉi tio estas platformo surbaze de kiu vi povas fari ion unikan, ion propran. Danke al ĉi tio, Linukso havas multajn distribuojn, kiuj diferencas en sia aro de programaraj komponantoj. Kaj jen problemo: por ke programaro funkciu en iu ajn distribuo, vi devas konsideri la funkciojn de ĉiu.
Pakaj administrantoj. .deb vs .rpm
Ni komencu kun la evidenta problemo distribui la produkton tra malsamaj distribuoj.
La plej tipa maniero distribui softvaraĵojn estas meti la pakaĵon en deponejon, por ke la pakaĵmanaĝero enkonstruita en la sistemon povu instali ĝin de tie.
Tamen, ni havas du popularajn pakformatojn: rpm и deb. Ĉi tio signifas, ke ĉiuj devos subteni.
En la mondo de deb-pakaĵoj, la nivelo de kongruo estas mirinda. La sama pakaĵo instaliĝas kaj funkcias same bone ĉe Debian 6 kaj Ubuntu 19.04. La normoj por la procezo konstrui pakaĵojn kaj labori kun ili, fiksitaj en malnovaj Debianaj distribuoj, restas trafaj en la nova Linux Mint kaj elementa OS. Tial, en la kazo de Veeam Agent por Linukso, sufiĉas unu deb-pakaĵo por ĉiu aparataro.
Sed en la mondo de rpm-pakaĵoj, la diferencoj estas grandaj. Unue, pro la fakto, ke ekzistas du tute sendependaj distribuistoj, Red Hat kaj SUSE, por kiuj kongruo estas tute nenecesa. Due, ĉi tiuj distribuistoj havas distribuajn kompletojn de tiuj. subteno kaj eksperimenta. Ankaŭ ne necesas kongruo inter ili. Montriĝis, ke el6, el7 kaj el8 havas siajn proprajn pakaĵojn. Aparta pako por Fedora. Pakoj por SLES11 kaj 12 kaj aparta por openSUSE. La ĉefa problemo estas dependecoj kaj pakaĵnomoj.
Problemo de dependeco
Bedaŭrinde, la samaj pakaĵoj ofte finiĝas sub malsamaj nomoj en malsamaj distribuoj. Malsupre estas parta listo de veeam-pakaĵdependencoj.
Por EL7:
Por SLES 12:
- libblkid
- libgcc
- libstdc++
- ncurses-libs
- fuze-libs
- dosiero-libs
- veeamsnap=3.0.2.1185
- libblkid1
- libgcc_s1
- libstdc++6
- libmagic1
- libfuse2
- veeamsnap-kmp=3.0.2.1185
Kiel rezulto, la listo de dependecoj estas unika por la distribuo.
Kio plimalboniĝas estas kiam ĝisdatigita versio komencas kaŝiĝi sub la malnova paknomo.
Ekzemplo:
La pako estis ĝisdatigita en Fedora 24 nmalbenoj de versio 5 ĝis versio 6. Nia produkto estis konstruita kun versio 5 por certigi kongruon kun pli malnovaj distribuoj. Por uzi la malnovan 5-an version de la biblioteko ĉe Fedora 24, mi devis uzi la pakaĵon ncurses-compat-libs.
Kiel rezulto, estas du pakaĵoj por Fedora, kun malsamaj dependecoj.
Plue pli interesa. Post la sekva distribua ĝisdatigo, la pako ncurses-compat-libs kun versio 5 de la biblioteko ĝi montriĝas neatingebla. Estas multekoste por distribuisto treni malnovajn bibliotekojn en novan version de la distribuo. Post iom da tempo, la problemo ripetiĝis en SUSE-distribuoj.
Kiel rezulto, kelkaj distribuoj devis faligi sian eksplicitan dependecon de ncurses-libs, kaj ripari la produkton por ke ĝi povu funkcii kun iu ajn versio de la biblioteko.
Cetere, en la versio 8 de Red Hat ne plu ekzistas meta-pakaĵo python, kiu rilatis al la bona malnova pitono 2.7... estas python2 и python3.
Alternativo al pakaĵadministrantoj
La problemo pri dependecoj estas malnova kaj jam delonge evidentiĝas. Nur memoru Dependeca infero.
Kombini diversajn bibliotekojn kaj aplikaĵojn por ke ili ĉiuj funkciu stabile kaj ne konfliktu - fakte, ĉi tiu estas la tasko, kiun ĉiu Linuksa distribuisto provas solvi.
La pakaĵa administranto provas solvi ĉi tiun problemon tute alimaniere. Rapida de Canonical. La ĉefa ideo: la aplikaĵo funkcias en sablokesto izolita kaj protektita de la ĉefa sistemo. Se aplikaĵo postulas bibliotekojn, ili estas liveritaj kun la aplikaĵo mem.
Flatpak ankaŭ permesas ruli aplikojn en sablokesto uzante Linuksajn Ujojn. La sablokesto-ideo ankaŭ estas uzata AppImage.
Ĉi tiuj solvoj permesas krei unu pakaĵon por iu ajn distribuo. En kazo de Flatpak instalado kaj lanĉo de la aplikaĵo eblas eĉ sen la scio de la administranto.
La ĉefa problemo estas, ke ne ĉiuj aplikoj povas funkcii en sablokesto. Iuj homoj bezonas rektan aliron al la platformo. Mi eĉ ne parolas pri kernaj moduloj, kiuj strikte dependas de la kerno kaj ne taŭgas en la sablokestokoncepto.
La dua problemo estas, ke distribuoj popularaj en la entreprena medio de Red Hat kaj SUSE ankoraŭ ne enhavas subtenon por Snappy kaj Flatpak.
Ĉi-rilate, Veeam Agent por Linukso ne haveblas ne sur .
Por fini la demandon pri pakaĵadministrantoj, mi ŝatus noti, ke ekzistas eblo forlasi pakaĵadministrilojn entute kombinante binarajn dosierojn kaj skripton por instali ilin en unu pakaĵon.
Tia pakaĵo permesas krei unu komunan pakaĵon por malsamaj distribuoj kaj platformoj, efektivigi interagan instalan procezon, efektivigante la necesan personigon. Mi nur renkontis tiajn pakaĵojn por Linukso de VMware.
Ĝisdatigi problemon
Eĉ se ĉiuj dependecaj problemoj estas solvitaj, la programo povas funkcii alimaniere en la sama distribuo. Temas pri ĝisdatigoj.
Estas 3 ĝisdatigaj strategioj:
- La plej simpla estas neniam ĝisdatigi. Mi instalis la servilon kaj forgesis pri ĝi. Kial ĝisdatigi se ĉio funkcias? Problemoj komenciĝas la unuan fojon kiam vi kontaktas subtenon. La kreinto de la distribuo nur subtenas la ĝisdatigitan eldonon.
- Vi povas fidi la distribuiston kaj agordi aŭtomatajn ĝisdatigojn. En ĉi tiu kazo, alvoko al subteno verŝajne tuj post malsukcesa ĝisdatigo.
- La opcio de mana ĝisdatigo nur post funkciado de ĝi sur testa infrastrukturo estas la plej fidinda, sed multekosta kaj tempopostula. Ne ĉiuj povas pagi ĝin.
Ĉar malsamaj uzantoj uzas malsamajn ĝisdatigajn strategiojn, necesas subteni kaj la plej novan eldonon kaj ĉiujn antaŭe publikigitajn. Ĉi tio komplikas kaj la procezon de disvolviĝo kaj testado kaj aldonas kapdolorojn al la subtena teamo.
Vario de aparataro platformoj
Malsamaj aparataj platformoj estas problemo plejparte specifa por denaska kodo. Minimume, vi devas kolekti binarojn por ĉiu subtenata platformo.
En la projekto Veeam Agent por Linukso, ni ankoraŭ ne povas subteni ion similan al ĉi tiu RISC.
Mi ne detale detalos pri ĉi tiu afero. Mi nur skizos la ĉefajn problemojn: platform-dependaj tipoj, kiel ekz size_t, strukturovicigo kaj bajta ordo.
Statika kaj/aŭ dinamika ligo
Sed la demando estas "Kiel ligi kun bibliotekoj - dinamike aŭ statike?" indas diskuti.
Kiel regulo, C/C++-aplikoj sub Linukso uzas dinamikan ligon. Ĉi tio funkcias bonege se la aplikaĵo estas konstruita specife por specifa distribuo.
Se la tasko estas kovri diversajn distribuojn per unu binara dosiero, tiam vi devas koncentriĝi pri la plej malnova subtenata distribuo. Por ni, ĉi tio estas Red Hat 6. Ĝi enhavas gcc 4.4, kiun eĉ la C++11-normo ne subtenas .
Ni konstruas nian projekton uzante gcc 6.3, kiu plene subtenas C++14. Nature, en ĉi tiu kazo, sur Red Hat 6 vi devas kunporti la libstdc++ kaj akceli bibliotekojn kun vi. La plej facila maniero estas ligi al ili statike.
Sed ve, ne ĉiuj bibliotekoj estas statike ligitaj.
Unue, sistembibliotekoj kiel ekz libfuse, libblkid necesas ligi dinamike por certigi ilian kongruon kun la kerno kaj ĝiaj moduloj.
Due, estas subtileco kun licencoj.
La GPL-licenco esence permesas vin ligi bibliotekojn nur per malfermfonta kodo. MIT kaj BSD permesas senmovan ligon kaj permesas al bibliotekoj esti inkluzivitaj en projekto. Sed la LGPL ŝajnas ne kontraŭdiri senmovan ligon, sed postulas ke la dosieroj necesaj por ligo estu kunhavataj.
Ĝenerale, uzi dinamikan ligon malhelpos vin devi provizi ion ajn.
Konstruado de C/C++-aplikoj
Por konstrui C/C++-aplikojn por malsamaj platformoj kaj distribuoj, sufiĉas elekti aŭ konstrui taŭgan version de gcc kaj uzi kruc-kompililojn por specifaj arkitekturoj kaj kunmeti la tutan aron de bibliotekoj. Ĉi tiu laboro estas sufiĉe realigebla, sed sufiĉe ĝena. Kaj ne estas garantio, ke la elektita kompililo kaj bibliotekoj provizos realigeblan version.
Evidenta avantaĝo: la infrastrukturo estas tre simpligita, ĉar la tuta konstruprocezo povas esti kompletigita per unu maŝino. Krome, sufiĉas kolekti unu aron da binaroj por unu arkitekturo kaj vi povas paki ilin en pakaĵojn por malsamaj distribuoj. Jen kiel veeam-pakaĵoj estas konstruitaj por Veeam Agent por Linukso.
Kontraste al ĉi tiu opcio, vi povas simple prepari konstruan bienon, tio estas, plurajn maŝinojn por kunigo. Ĉiu tia maŝino provizos aplikaĵan kompilon kaj pakaĵaron por specifa distribuo kaj specifa arkitekturo. En ĉi tiu kazo, kompilo estas farita per la rimedoj preparitaj de la distribuisto. Tio estas, la stadio de preparado de la kompililo kaj elekto de bibliotekoj estas forigita. Krome, la konstruprocezo povas esti facile paraleligita.
Estas tamen malavantaĝo al ĉi tiu aliro: por ĉiu distribuo ene de la sama arkitekturo, vi devos kolekti vian propran aron de binaraj dosieroj. Alia malavantaĝo estas, ke tia granda nombro da maŝinoj devas esti konservita kaj granda kvanto da diskospaco kaj RAM devas esti asignita.
Jen kiel KMOD-pakaĵoj de la veeamsnap-kernmodulo estas kompilitaj por Red Hat-distribuoj.
Malfermu Konstruan Servon
Kolegoj de SUSE provis efektivigi ian mezan vojon en la formo de speciala servo por kompili aplikaĵojn kaj kunmeti pakaĵojn - .
Esence, ĝi estas hiperviziero, kiu kreas virtualan maŝinon, instalas ĉiujn necesajn pakaĵojn en ĝi, kompilas la aplikaĵon kaj konstruas la pakaĵon en ĉi tiu izolita medio, post kio la virtuala maŝino estas liberigita.
La planilo efektivigita en OpenBuildService determinos kiom da virtualaj maŝinoj ĝi povas lanĉi por optimuma pakkonstrua rapideco. La enkonstruita subskriba mekanismo subskribos la pakaĵojn kaj alŝutos ilin al la enkonstruita deponejo. La enkonstruita versio-kontrolsistemo savos la historion de ŝanĝoj kaj konstruoj. Restas nur aldoni viajn fontojn al ĉi tiu sistemo. Vi eĉ ne devas mem agordi la servilon; vi povas uzi malfermitan.
Estas tamen problemo: tian rikoltmaŝinon malfacile konvenas en la ekzistantan infrastrukturon. Ekzemple, versio-kontrolo ne estas bezonata; ni jam havas nian propran por fontkodoj. Nia subskriba mekanismo estas malsama: ni uzas specialan servilon. Deponejo ankaŭ ne necesas.
Krome, subteno por aliaj distribuoj - ekzemple, Red Hat - estas sufiĉe malbone efektivigita, kio estas komprenebla.
La avantaĝo de tia servo estas rapida subteno por la sekva versio de la SUSE-distribuo. Antaŭ la oficiala anonco de la liberigo, la pakaĵoj necesaj por kunigo estas afiŝitaj en publika deponejo. Nova aperas en la listo de disponeblaj distribuoj ĉe OpenBuildService. Ni kontrolas la skatolon kaj ĝi estas aldonita al la konstruplano. Tiel, aldoni novan version de la distribuo estas farita en preskaŭ unu klako.
En nia infrastrukturo, uzante OpenBuildService, la tuta vario de KMP-pakaĵoj de la veeamsnap-kerna modulo por SUSE-distribuoj estas kunvenita.
Poste, mi ŝatus pritrakti aferojn specifajn por kernaj moduloj.
kerno ABI
Linuksaj kernomoduloj historie estis distribuitaj en fontformo. La fakto estas, ke la kreintoj de la kerno ne ŝarĝas sin per la zorgo subteni stabilan API por kernaj moduloj, kaj precipe ĉe la binara nivelo, plue nomata kABI.
Por konstrui modulon por vanila kerno, vi certe bezonas la kapojn de ĉi tiu aparta kerno, kaj ĝi funkcios nur sur ĉi tiu kerno.
DKMS permesas vin aŭtomatigi la procezon de konstruado de moduloj dum ĝisdatigado de la kerno. Kiel rezulto, uzantoj de la Debiana deponejo (kaj ĝiaj multaj parencoj) uzas kernmodulojn aŭ de la deponejo de la distribuisto aŭ kompilitaj de fonto uzante DKMS.
Tamen, ĉi tiu situacio ne precipe konvenas al la Enterprise-segmento. Propraj koddistribuistoj volas distribui la produkton kiel kompilitaj binaroj.
Administrantoj ne volas konservi evoluilojn sur produktaj serviloj pro sekurecaj kialoj. Entreprenaj Linuksaj distribuistoj kiel Red Hat kaj SUSE decidis ke ili povus subteni stabilan kABI por siaj uzantoj. La rezulto estis KMOD-pakaĵoj por Red Hat kaj KMP-pakaĵoj por SUSE.
La esenco de ĉi tiu solvo estas sufiĉe simpla. Por specifa versio de la distribuo, la kerno API estas frostigita. La distribuisto deklaras ke li uzas la kernon, ekzemple, 3.10, kaj faras nur korektojn kaj plibonigojn kiuj ne influas la kerninterfacojn, kaj la moduloj kolektitaj por la plej unua kerno povas esti uzataj por ĉiuj postaj sen rekompilo.
Red Hat asertas kABI-kongruon por la distribuo dum ĝia tuta vivociklo. Tio estas, la kunmetita modulo por rhel 6.0 (eldono de novembro 2010) ankaŭ devus funkcii en versio 6.10 (eldono de junio 2018). Kaj ĉi tio estas preskaŭ 8 jaroj. Kompreneble, ĉi tiu tasko estas sufiĉe malfacila.
Ni registris plurajn kazojn, kie la modulo veeamsnap ĉesis funkcii pro problemoj de kongrueco de kABI.
Post kiam la modulo veeamsnap, kompilita por RHEL 7.0, montriĝis nekongrua kun la kerno de RHEL 7.5, sed ĝi ŝargis kaj garantiis kraŝi la servilon, ni tute forlasis la uzon de kABI-kongruo por RHEL 7.
Nuntempe, la KMOD-pakaĵo por RHEL 7 enhavas aron por ĉiu eldonversio kaj skripton, kiu ŝarĝas la modulon.
SUSE pli zorge tuŝis la taskon de kABI-kongruo. Ili provizas kABI-kongruecon nur ene de unu serva pako.
Ekzemple, la liberigo de SLES 12 okazis en septembro 2014. Kaj SLES 12 SP1 jam estis en decembro 2015, tio estas, iom pli ol unu jaro pasis. Eĉ se ambaŭ eldonoj uzas la 3.12-kernon, ili estas kABI nekongruaj. Evidente, konservi kABI-kongruecon dum nur jaro estas multe pli facila. La ĉiujara ĝisdatiga ciklo de la kerno-modulo ne devus kaŭzi problemojn por la kreintoj de modulo.
Kiel rezulto de ĉi tiu SUSE-politiko, ni ne registris eĉ unu problemon kun kABI-kongruo en nia veeamsnap-modulo. Vere, la nombro da pakaĵoj por SUSE estas preskaŭ grandordo pli granda.
Flikiloj kaj backports
Kvankam distribuistoj provas certigi kABI-kongruon kaj kernan stabilecon, ili ankaŭ provas plibonigi la agadon kaj forigi difektojn de ĉi tiu stabila kerno.
Samtempe, krom sia propra "laboro pri eraroj", la programistoj de la entrepreno Linuksa kerno monitoras ŝanĝojn en la vanila kerno kaj transdonas ilin al sia "stabila".
Kelkfoje ĉi tio kondukas al novaj .
En la plej nova eldono de Red Hat 6, eraro estis farita en unu el la malgrandaj ĝisdatigoj. Ĝi kondukis al la fakto, ke la veeamsnap-modulo estis garantiita kraŝi la sistemon kiam la momentfoto estis publikigita. Komparinte la kernfontojn antaŭ kaj post la ĝisdatigo, ni eksciis, ke kulpas la backport. Simila riparo estis farita en la vanila kerno versio 4.19. Estas nur, ke ĉi tiu riparo bone funkciis en la vanila kerno, sed kiam oni translokigis ĝin al la "stabila" 2.6.32, aperis problemo kun la spinlock.
Kompreneble ĉiuj ĉiam havas erarojn, sed ĉu indas treni la kodon de 4.19 al 2.6.32, riskante stabilecon?... Mi ne certas...
La plej malbona afero estas kiam merkatado engaĝiĝas en la ŝnur-ŝnuro inter "stabileco" kaj "modernigo". La merkatada fako bezonas, ke la kerno de la ĝisdatigita distribuo estu stabila, unuflanke, kaj samtempe esti pli bona en rendimento kaj havi novajn funkciojn. Ĉi tio kondukas al strangaj kompromisoj.
Kiam mi provis konstrui modulon sur kerno 4.4 de SLES 12 SP3, mi estis surprizita trovi funkciecon de vanilo 4.8 en ĝi. Laŭ mi, la bloka I/O efektivigo de la 4.4-kerno de SLES 12 SP3 estas pli simila al la 4.8-kerno ol la antaŭa eldono de la stabila 4.4-kerno de SLES12 SP2. Mi ne povas juĝi, kian procenton de kodo estis translokigita de kerno 4.8 al SLES 4.4 por SP3, sed mi eĉ ne povas nomi la kernon la sama stabila 4.4.
La plej malagrabla afero pri tio estas, ke kiam oni verkas modulon, kiu funkcius same bone sur malsamaj kernoj, oni ne plu povas fidi la kernan version. Vi ankaŭ devas konsideri la distribuon. Estas bone, ke foje vi povas partopreni en difino, kiu aperas kune kun nova funkcieco, sed ĉi tiu ŝanco ne ĉiam aperas.
Kiel rezulto, la kodo iĝas superkreskita de strangaj kondiĉaj kompildirektivoj.
Estas ankaŭ diakiloj, kiuj ŝanĝas la dokumentitan kernan API.
Mi renkontis la distribuadon 5.16 kaj estis tre surprizita vidi ke la alvoko lookup_bdev en ĉi tiu kernversio ŝanĝis la liston de eniga parametroj.
Por kunigi ĝin, mi devis aldoni skripton al la makedosiero, kiu kontrolas ĉu la funkcio lookup_bdev havas maskan parametron.
Subskribado de kernaj moduloj
Sed ni revenu al la afero de pakaĵdistribuo.
Unu el la avantaĝoj de stabila kABI estas ke kernomoduloj povas esti subskribitaj kiel binara dosiero. En ĉi tiu kazo, la programisto povas esti certa, ke la modulo ne estis hazarde damaĝita aŭ intence modifita. Vi povas kontroli ĉi tion per la komando modinfo.
Red Hat kaj SUSE-distribuoj permesas vin kontroli la subskribon de la modulo kaj ŝargi ĝin nur se la responda atestilo estas registrita en la sistemo. La atestilo estas la publika ŝlosilo per kiu la modulo estas subskribita. Ni distribuas ĝin kiel apartan pakaĵon.
La problemo ĉi tie estas, ke atestiloj povas aŭ esti enkonstruitaj en la kernon (distribuistoj uzas ilin) aŭ devas esti skribitaj al EFI ne-volatila memoro uzante ilon. mokutil. Utilo mokutil Instalante atestilon, ĝi postulas, ke vi rekomencu la sistemon kaj, eĉ antaŭ ol ŝargi la operaciuman kernon, instigas la administranton permesi ŝarĝon de nova atestilo.
Tiel, aldoni atestilon postulas fizikan administrantan aliron al la sistemo. Se la maŝino situas ie en la nubo aŭ simple en fora servila ĉambro kaj aliro estas nur per la reto (ekzemple, per ssh), tiam estos neeble aldoni atestilon.
EFI sur virtualaj maŝinoj
Malgraŭ la fakto, ke EFI delonge estas subtenata de preskaŭ ĉiuj baztabulo-fabrikistoj, dum la instalado de sistemo, la administranto eble ne pensas pri la bezono de EFI, kaj ĝi povas esti malŝaltita.
Ne ĉiuj hiperviziiloj subtenas EFI. VMWare vSphere subtenas EFI ekde versio 5.
Microsoft Hyper-V ankaŭ akiris EFI-subtenon komencante kun Hyper-V por Windows Server 2012R2.
Tamen, en la defaŭlta agordo ĉi tiu funkcio estas malŝaltita por Linuksaj maŝinoj, kio signifas, ke la atestilo ne povas esti instalita.
En vSphere 6.5, agordu la opcion Sekura Boot ebla nur en la malnova versio de la TTT-interfaco, kiu funkcias per Flash. Retejo UI sur HTML-5 estas ankoraŭ multe malantaŭe.
Eksperimentaj distribuoj
Kaj fine, ni konsideru la aferon de eksperimentaj distribuoj kaj distribuoj sen oficiala subteno. Unuflanke, tiaj distribuoj verŝajne ne troviĝas sur la serviloj de seriozaj organizoj. Ne ekzistas oficiala subteno por tiaj distribuoj. Tial donu tiujn. La produkto ne povas esti subtenata en tia distribuo.
Tamen tiaj distribuoj fariĝas oportuna platformo por provi novajn eksperimentajn solvojn. Ekzemple, Fedora, OpenSUSE Tumbleweed aŭ Unstable versioj de Debiano. Ili estas sufiĉe stabilaj. Ili ĉiam havas novajn versiojn de programoj kaj ĉiam novan kernon. Post unu jaro, ĉi tiu eksperimenta funkcio povas finiĝi en ĝisdatigita RHEL, SLES aŭ Ubuntu.
Do se io ne funkcias en eksperimenta distribuo, ĉi tio estas kialo por eltrovi la problemon kaj solvi ĝin. Vi devas esti preta por la fakto, ke ĉi tiu funkcio baldaŭ aperos sur produktaj serviloj de uzantoj.
Vi povas studi la nunan liston de oficiale subtenataj distribuoj por versio 3.0 . Sed la vera listo de distribuoj sur kiuj nia produkto povas funkcii estas multe pli larĝa.
Persone, mi interesiĝis pri la eksperimento kun la Elbrus OS. Post finpretigo de la veeam-pakaĵo, nia produkto estis instalita kaj funkcianta. Mi skribis pri ĉi tiu eksperimento pri Habré en .
Nu, subteno por novaj distribuoj daŭras. Ni atendas la eldonon de la versio 4.0. Beta estas aperos, do atentu !
fonto: www.habr.com