Van egy szép projekt a github-on, nevezetesen ő: openscad-wasm. Szeretném lefordítani, de dockert kér a fordításhoz amit szeretnék elkerülni. Minden függősége része a rendszeremnek ha akarom, de le is töltötte magának a megfelelő verziót a "make all", aztán a build megáll a docker hiányára hivatkozva. Kérnék egy tippet, hogy hogyan tehetném meg docker nélkül, mit kellene a makefile-ban változtatni? Illetve mi az előnye, hogy alig találni forráskódot amit ne konténerbe erőltetnének? Ez például elvben egy javascript programot eredményez, amit ha készen van betolok a megfelelő helyre a webszerveren és működik docker nélkül. Nem szeretem a dockert...
A fenti fordítás eredményét szeretném Wordpressbe integrálni valahogyan. Hogyan lehet/érdemes ezt megtenni? Plugint sosem írtam, php-ban viszont webshopot is még a php5 idején és azóta semmit :) Valójában az is megfelelne, ha az openscad-ot gui gélkül tudnám fordítani debianra és az eredményt mondjuk valami stl megjelenítővel a wordpress megmutatná 3d-ben amit az egérrel lehetne cincálni az ablakban. Semmi kód módosítás, csak megjelenítés esetleg 3-4 paraméterezhető dolgot változóként átadva. Persze jó lenne a szerveren renderelni, hogy akkor is lehessen változtatásokat csinálni ha nem vagyok gépközelben és az sem lenne utolsó ha ehhez nem a webszervert kell igénybe venni.
Ha már webszerver. Van pár VPS-em, működik minden ahogy kell (amikor minden működik). Van 2 domain-em, az egyik amúgy jelenleg nem használt. Szeretném ennek a névszerverét egy sajátra kicserélni és aldomaineket létrehozni/kezelni. Semmi konkrét világmegváltás, csak ismerkednék ezzel is. Itthon az unbound-ot használom a belső hálón ami most egy proxy/cache/reklámblokkoló. Néha frissítek a blocklistán, de amúgy teszi a dolgát szó nélkül. Hogyan lehetne ezt a DNS szolgáltatást erre az egy domainre átvenni a regisztrátortól mondjuk az unbound-al? Van egy kis VPS-em ami azon kívül, hogy van semmit nem csinál, ott szívesen kipróbálnám.
Így hirtelen ennyi, de csak mert nem akarok egyszerre túl sokat :) A Blogba tettem, nem akartam hirtelen ennyi külön fórumtémát nyitni, bár lehet, hogy célszerűbb lett volna. Néhány dolog könnyen megy fejben nálam viszont van amit nehezen sem fogok fel, szóval csak türelmesen :) Kérnék linkeket és /vagy magyarázatokat.
- dzsolt blogja
- A hozzászóláshoz be kell jelentkezni
- 414 megtekintés
Hozzászólások
A Docker azért kell, mert ahogy nézem elég bonyolult e lib fordítása, így megspórolják a fejlesztők az user számára, hogy felrakja az összes fordításhoz szükséges programot és libet a gépére, ami komoly munka lehet. A fordítás után letörölheted az összes konténert, szóval még helyet se fognak foglalni. Azonban, ha nagyon sok szabadidőd van és vállalkozó kedvedben vagy, akkor végigkövetheted a Dockerfile-okban lévő parancsokat: a Dockerfile.base-ben fordít pár kiegészítő libet, a Dockerfile-ban pedig egy cmake-kel fordítja magát a openscad-wasm libet.
3D megjelenítő van bőven, pl. https://threejs.org/ vagy https://kitware.github.io/vtk-js/examples/ előbbihez még WP plugin is van, de 1-2 lib beágyazásával berakható kézzel is.
- A hozzászóláshoz be kell jelentkezni
Köszönöm a linkeket, a threejs jónak tűnt, amíg ki nem derült, hogy nem ismeri az openscad egyik kimeneti formátumát sem :(
... így megspórolják a fejlesztők az user számára, hogy felrakja az összes fordításhoz szükséges programot és libet a gépére, ami komoly munka lehet.
Bakker, így is fel kell tenni és bár a konténert letörölhetem, szeretnék vele egy kicsivel több időt tölteni, így akár maradhatna konténer nélkül is a rendszeremen. Egy install-remove nem ördögtől való egy rendszeren sem :)
A dockerre nem szeretnék sok időt fordítani, így valószínűleg telepítem és ha megy gond nélkül, azt fogom használni, ha nem akkor passz... a rendszeremen (gentoo) minden telepítve van ami a fordításhoz kellhet, de le is töltötte a make all. Mi a fenének kell ezt még egy konténerbe beletolni? :D Értem én, hogy menő a docker meg az összes konténer technika, de úgy vagyok ezzel, mint sok ma divatból használt dologgal (elmélettel, politikával, vallással, miegyébbel), hogy pont ezzel veszik el az értelme! Vannak egészen kis projektek, egy darab python kód fut(na), de docker nélkül halandónak (docker ismeretek nélküli halandónak) nincs esélye használni (illetve van ha telepítve van a docker, de az meg minek egy mezei user gépre?!). :( Ezt erőltetettnek, divatmajmolásnak találom! A javaslatod jó, végig is követném ha legalább fogalmam volna, hogy mit kell kezdjek a dockerfile tartalmával. Persze előfordulhat, hogy rájövök mi miért van, de nem akartam erre időt pocsékolni, de lehet nem úszom meg! Remélem soha nem lesz szükségem rá többé, ezért nem szerettem volna vele semmit az életben kezdeni.
„Niemand ist unnütz! Man kann immer noch als schlechtes Beispiel dienen!”
dzsolt
- A hozzászóláshoz be kell jelentkezni
"egy darab python kód fut(na), de docker nélkül halandónak (docker ismeretek nélküli halandónak) nincs esélye használni" - Amikor 1234-féle disztrón 23456-féle kombinációban vannak egymással nagyjából kompatibilis komponensek, megfejelve az adott csomagok karbantartójának az esetleges agymenéseivel, akkor egyszerűbb egy konténerbe összelapátolni mindazt, amivel tökéletesen működik a cucc, mint a 23456-féle környezetből mondjuk 3456-ról érkező 6543 különböző "bugot" kireszelni...
De ahogy előttem is írták, összerakhatod a saját OS-edben is azokat a komponenseket, amiket a buildhez konténerbe pakolna, és kézzel végigtolhatod a folyamatot...
- A hozzászóláshoz be kell jelentkezni
Igazad lehet, én nem érzem át teljesen, mert még nem ütköztem ilyen problémába.
De ahogy előttem is írták, összerakhatod a saját OS-edben is azokat a komponenseket, amiket a buildhez konténerbe pakolna, és kézzel végigtolhatod a folyamatot...
Azt hiszem ez lesz... bár még az is lehet, hogy felrakom az app-containers/docker csomagot, mert Size of downloads: 30.985 KiB még nem a világ vége.
„Niemand ist unnütz! Man kann immer noch als schlechtes Beispiel dienen!”
dzsolt
- A hozzászóláshoz be kell jelentkezni
a threejs jónak tűnt, amíg ki nem derült, hogy nem ismeri az openscad egyik kimeneti formátumát sem
STL-t tud szinte minden 3D megjelenítő. https://threejs.org/examples/webgl_loader_stl.html
A Docker elsőre valóban fölöslegesnek tűnhet, ha még sosem használtad. Azonban megvan az alkalmazási területe, ahol nagyon hasznos célszerszám. Pl. ennél a 3D modellező WASM fordításánál több tucatnyi libre van szükség. Mi van ha nálad egy korábbi változat van meg belőlük? Mi van ha nem tudsz felrakni belőlük újat, mert ütközik egy másik csomaggal? Valszeg amúgy is egy valamennyire szeparált környezetbe raknád fel a csomagokat és ott fordítanád le. A Docker ezt csinálja sztenderd/reprodukálható módon.
Vagy ha már Python: nálad pl. 3.9 van, egy szkript meg 3.10-et használna. Docker erre is megoldás lehet. Vagy ha már említetted a PHP-t és a VPS-t. Van 3 szkripted: egy ősrégi 5.6-os, egy újabb 7.2-es és egy zsír új 8.1-es PHP-t igénylő. Dockerrel könnyedén készíthetsz egy-egy szeparált környezetet ezeknek, nem fogják egymást zavarni. Mindegyikhez tartozhat akár egy külön verziós MySQL is, a régi 5.6-os szkript nem biztos, hogy kompatibilis MySQL 8-as változattal. Dockerrel összerakhatsz bármilyen, a host OS-tól független környezetet némi extra tárhelyért cserébe.
A Dockerrel összerakott környezetet meg használhatod lokális fejlesztőkörnyezetként is. Fel tudsz mountolni egy helyi könyvtárat a konténerbe, így a helyileg szerkesztett fájlokat a Docker környezetben tudod futtatni. Vagy ha esetleg van VS Code is a gépeden, azzal "remote" üzemmódban lehet közvetlen egy konténerben is fejleszteni.
- A hozzászóláshoz be kell jelentkezni
Ez a leírást elszúrtam, a threejs tudná, a worpress plugin nem tudja, bocsánat (hátha valaki pont emiatt tévedne tévútra)! Most szögelem a threejs-t a worpresshez, talán sikerül is :)
Docker. Értem én, hogy mire való, használok chroot-ot (gyakran) és ha komplett os kell akkor mkosival csinálok gépeket (például az onlyoffice fordításhoz debiant). Ha szükség van valamire, akkor megoldható dockerezés nélkül is, de ha egy fejlesztés kifejezetten dockerre épül, abból kihámozni némi docker ismeretre van szükség ami nekem nincsen!!! A különböző python, php verziók egyidejű futtatásának lehetősége pedig sehol nincs jobban megoldva, mint gentoo-n. Debianon szívás, ha mondjuk egy webes leírást követve csak bedobod, hogy apt install php-valami, mert a legfrisebb elérhetőt rántja azonnal, agyoncsapva a jól beállított rendszered (vagy csak én nem találtam egy egyszerű eselect set default parancsnak megfelelőt debianon. Amúgy szeretem a debiant, megtanultam erre figyelni.) A pythonból is csak akkor látnám értelmét egy akármilyen konténernek a gentoo rendszeremen, ha a régi verziók rendszerszintűen elérhetőek lennének általa (mondjuk a 2.7), mert van pár máig nem pótolt alkalmazás ami így kiesett a pixisből. Ezt a szeparált konténerkörnyezetet talán azért nem értem igazán, mert nem érzem át a szükségességét, megoldja a gentoo konténer nélkül. A rendszeremen több verzió is megfér egymás mellett és van egy default. Ami nem az, azt a megfelelő módon kell telepíteni és az életben többé nem kell tudnom róla, hogy a háttérben épp a 3.8 vagy a 3.10-es pythont hívogatja. PHP dettó. A szerverekre meg nem teszek fel csak olyasmit ami működik az adott környezetben, azzal nincs kedvem vacakolni. Ott működnie kell. Ami nincs még/már az várat magára vagy repül és jön helyette más ami kompatibilis.
Ennél a WASM projektnél pedig ahogy írtam, a make all lerántotta az összes függőséget és ezek nagy része amúgy is kell az asztali openscad fordításhoz. A verziókat összevetve pedig nem is sok változás kellene a rendszeren, simán követhető a portageból. Értem én, hogy a végén eldobhatod, de nem eldobni akarom, hanem lefordítani és aztán megint és talán megint. Nem vitatkozni akarok a docker szükségességét illetően, inkább sajnálkozom, hogy mindenhatónak van beállítva és divatból építkeznek rá. Bizonyára van olyan, ahol mára megkerülhetetlen, nem kétlem. A VS-Code-ot meg messzire elkerülöm, nekem túl pofátlan az eredménye. A geany a kiegészítőivel megfelelt eddig mindenre, bár a mikrokontrollerek feltöltésével szívtam eleget míg rá nem sikerült jönni.
„Niemand ist unnütz! Man kann immer noch als schlechtes Beispiel dienen!”
dzsolt
- A hozzászóláshoz be kell jelentkezni
A verziókat összevetve pedig nem is sok változás kellene a rendszeren, simán követhető a portageból.
Más meg mondhatja azt, hogy egy lib fordítása miatt rontsam el a lokális rendszert? Akkor inkább egy VM, vagy Docker, a saját rendszeremet hagyja békén.
Nem látom, hogy divatból építkeznének konténerekre (pláne webes projekteknél). Sokkal inkább a letesztelt, reprodukálható környezet miatt. Nem akarnak olyan kérdésekkel foglalkozni, hogy nekem xy rendszerem van ilyen-olyan csomagokkal, miért nem működik nálam a program fordítás után?
Persze, ha max egy PHP szkriptet futtatsz a VPS-en, akkor tényleg fölösleges. Azonban ha valami komplexebb szolgáltatást több background workerrel, adatbázis, redis, stb. akkor lehet Dockerrel könnyebb már megoldani.
- A hozzászóláshoz be kell jelentkezni
Ne haragudj, de amióta gentoozom (több, mint 20 éve), mindent forrásból építek. Látom a trendet (korábban a docker opció volt a projektek építése során, ma meg függőség sok (felesleges) esetben) és ahogy már írtam van helye csak ez kb. olyan, mit az LMBQ+-*/. Nekem semmi bajom nem volt egyikkel sem, de minél inkább erőltetik, annál ellenszenvesebb.
„Niemand ist unnütz! Man kann immer noch als schlechtes Beispiel dienen!”
dzsolt
- A hozzászóláshoz be kell jelentkezni
Vedd úgy, hogy nem a Dockert erőltetik, hanem a régi, sok problémával járó módszert hanyagolják. Ha a jövőben lesz még jobb megoldás, akkor arra fognak átállni a projektek.
- A hozzászóláshoz be kell jelentkezni
Ezt már most csak témán kívül, úgy, hogy természetesen tudom: megvan a helye a docker konténerezésnek. Írtam, ahol szükségem van rá, különböző módszerekkel használom a szeparált környezetek kialakítását. Szóval értelek is meg nem is :) Nekem ez olyan kenyérszeletelővel kenem a vajat/margarint, mert már a kezemben van. Közben persze kibököm a plasztikdoboz oldalát, akár többször is, de majd befoltozom mielőtt kidobnám. Ha van egy rendszerszintű megoldás valamire, akkor szeretem azt kihasználni és az erőforrásokkal (tárhely, ram, processzor, stb...) jól gazdálkodni. Az is igaz, hogy a mai világban a tárhely olcsó, a processzorok erősebbek, gyorsabb a ram, tehát nem megerőltető néhány éve ez a technika. Én a Z80 időkben kezdem programozni, onnan a mikrovezérlőkre és a linux irányába indultam. Valahogy beivódott, hogy az erőforrás véges. A docker "mindenhováis" alkalmazása nem erőforráskímélő, inkább pazarló. Gyakran olvasom a hup-on is, hogy valaki valamit keres és melléírja, hogy a dockert hanyagolná. Ha mondjuk egy friss debian alá be kell nyomni még egy fél (amúgy már meglévő) debiánt, mert a dockerben benne van és a fejlesztés nem ismeri a dockeren kívüli futtatás lehetőségét, akkor az pazarlás. Értem én, hogy univerzális lett és most már fut az új cirokseprőn is meg a régi rakéta porszívón, de kár, hogy a fejlesztője azt hiszi, hogy a régi, sok problémával járó módszert hanyagolja, mert éppen ellenkezőleg! Új problémákat okoz a dockerrel amik anélkül nem is lettek volna! A dockerbe került csomagok is lettek valahonnan, a függőségi fát kilistázni nem űrtechnika. A korábbi példám az onlyoffice fordítás. Gentoom van ez meg debianon fordul (vagy ubuntun, de azt végképp nem szeretnék). Az mkosival csinálok egy debian telepítést és a machinectl indítja. Ez rendben van, két különböző rendszer. Ezen kívül van egy hivatalos buildserver docker ág és az is használható. Ami a dockerbe fut, azt kell a chroot-ban vagy a vm-ben is futtatni, mindezt úgy, hogy ha nem akarok a dockerrel ismerkedni, nem kell. Ha belenézek egy docker konténerbe a sok krixkrax könyvtárait nem mondanám barátságosnak. Mondjuk ugyanez lehet ugyanennyire kusza az mkosival is, de még mindig ott a választás lehetősége, hogy ha nem akarom nem kell :) Viszont ha függ a dockertől akkor ha akarom, ha nem... Ennyi a történetem a dockerrel.
„Niemand ist unnütz! Man kann immer noch als schlechtes Beispiel dienen!”
dzsolt
- A hozzászóláshoz be kell jelentkezni
Szerintem az a baj a Dockerrel, hogy egy olyan problémát old meg, _aminek nem lenne szabad létezni_. De sajnos a valóság meg az, hogy _a probléma létezik_. Ezért a Dockernek létjogosultsága van, szükségünk van rá és hasznos.
Én is idegenkedtem tőle elsőre, de baromi jó dolog a docker. Igen, zabálja az SSD-t és talán a RAM-ot is, de ezek filléres tételek a fejlesztő idejéhez képest.
- A hozzászóláshoz be kell jelentkezni
Subscribe. Ha jól értem az a célod, hogy OpenSCAD modelleket weben megjeleníts automatikusan, igaz? Ha könnyen megoldható lenne én is szívesen csinálnék ilyet.
Az OpenSCAD WASM mit tudna pontosan?
A szerver oldali és a kliens oldali render között a legfontosabb különbség az, hogy amit a kliensen csinálsz a szerveredet nem terheli. De ha nincs nagy terhelés, akkor sokszor egyszerűbb a szerveren csinálni szinte mindent. Az OpenSCAD-en belül van egy preview, ami nagyon gyors és egy render, ami nálam idegesítően lassú. A WASM változattal a gyors render működne browseren belül futtatva?
- A hozzászóláshoz be kell jelentkezni
Igen, ilyesmi. A kódot nem mutatná egy szerkesztőben, mint ahogyan az OpenSCAD teszi, hanem csak a renderelt képet. (Most találtam valamit ami automatikusan frissíti a renderelt képet, dolgozom rajta, hátha rájövök miként teszi). Mellette lenne egy beviteli mező amiben pár paramétert lehetne megadni, olyanok mint mértékegység (mm/inch), átmérő, magasság, anyagvastagság, lekerekítés elől vagy hátul vagy mind a két oldalon és ezeknek a mértéke. Ez nem gyártásra készül, hanem szemléltetésre. A végén akár a kész scad fájl is letölthető lehetne vagy csak egy stl.
Tőlem mehetne az openscad is a szerverre, ha nem rántaná magával a fél világot. Igyekszem a szervereken olyan keveset amilyen keveset lehet és olyan sokat amilyen sokat muszáj telepíteni. A sallangok csak hibaforrás.
Az OpenSCAD WASM céja egy webassemblyben megírt teljes funkcionalitású OpenSCAD. Itt elég gyorsan átveszi a változtatásokat, de a fan_wheel példa script a https://mastering-openscad.eu/buch/ oldalról már nem fut le, a cilinder látszik csak. A renderelés sajnos nem gyors. Egy bonyolultabb felület az asztalin sem gyors, ebben még lassabb és sajnos nem is ismer mindent. Amire én szeretném, azok mennek, de nem teljes értékű sajnos :(
„Niemand ist unnütz! Man kann immer noch als schlechtes Beispiel dienen!”
dzsolt
- A hozzászóláshoz be kell jelentkezni