- trey blogja
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Mi nem tetszett az eredeti ábrán?
Tudod egy Windows Server egészen addig Windows Server marad, amíg nem telepítesz rá Hyper-V-t mint Hypervisort.
Aláírás _Franko_ miatt törölve.
neut @
- A hozzászóláshoz be kell jelentkezni
Szerinted egy Vmware ESXi melyik kategória? Ha pedig az Type-1 és piacvezető, akkor miért Type-2-vel hasonlítgatják? Kirúgom onnan az op. rendszert és máris egyforma magad a két kupac.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Az ábrához: a traditional deploymentnél is van bin/library, ha már a másikra felrajzolták, akkor ide is fel kellene tenni.
Jól látszik ezeken az ábrákon, hogy ha a függőség-kezelés tisztességesen meg volna csinálva, akkor az egész konténerizálás felesleges volna. Ez egy nagyon komplex és nagyon drága workaround arra a problémára, hogy egy program egzaktul meg tudja mondani, hogy ő milyen könyvtárakat használva szeretne futni, illetve hogy ezek a könyvtárak egymás mellett tudjanak élni anélkül, hogy az egyik frissítése bolygatná a másikat.
- A hozzászóláshoz be kell jelentkezni
Hát, istenem! Maguk felé hajlott a rajzoló kezük!
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Én is pont így érzem, hogy a csomagkezelés (szándékos?) hiányosságait úgy sikerült elfedni, hogy kidobjuk az egészet.
- A hozzászóláshoz be kell jelentkezni
Igen is, meg nem is. A kontenerizalas azert joval tobbet nyujt, mint egy flatpak/snap/appimage. Jogosultsagkezeles, halozatkezeles, stb.
- A hozzászóláshoz be kell jelentkezni
unshare/cgroup/seccomp izolálás workaroundra akár elég is lehetne?
- A hozzászóláshoz be kell jelentkezni
Jól látszik ezeken az ábrákon, hogy ha a függőség-kezelés tisztességesen meg volna csinálva, akkor az egész konténerizálás felesleges volna.
Nem a függőség kezelés a container deployment lényege, ha pont ugyanaz a függősége mindegyik deployment-nek, akkor is lényeges a container abban, hogy egymástól teljesen függetlenné teszi az alkalmazásokat jelentős overhead nélkül, mintha külön VM-ben futnának egyenként, korlátozott erőforrásokkal. De például lehetővé válik az is, hogy egyesével frissítsd őket, anélkül, hogy egy nagy élesítésbe kelljen összevárnod az összes alkalmazást, amíg mindegyik függősége ugyanaz nem lesz. Arra is könnyen lehetőséget ad, hogy A/B tesztként vagy canary release formájában ugyanabból az alkalmazásból kipróbálj egy újabb vagy frissített függőségű alkalmazást is, olyan kockázat nélkül, hogy egy komplett rendszert kelljen visszaállítanod, ha hiba derül ki. Amíg nem érted meg a container deployment jelentőségét, addig azt fogod gondolni, hogy faszság. Ha megérted, akkor viszont rá fogsz jönni, hogy mennyi előnye van a korábbi megoldásokhoz képest.
Ez egy nagyon komplex és nagyon drága workaround arra a problémára, hogy egy program egzaktul meg tudja mondani, hogy ő milyen könyvtárakat használva szeretne futni, illetve hogy ezek a könyvtárak egymás mellett tudjanak élni anélkül, hogy az egyik frissítése bolygatná a másikat.
Tulajdonképpen feltaláltad a konténert, mert ezzel egy program egzaktul meg tudja mondani, hogy ő milyen könyvtárakat használva szeretne futni és ezek egymás mellett tudjanak élni anélkül, hogy az egyik frissítése bolygatná a másikat.
- A hozzászóláshoz be kell jelentkezni
>Ez egy nagyon komplex és nagyon drága workaround arra a problémára, hogy egy program egzaktul meg tudja mondani, hogy ő milyen könyvtárakat használva szeretne futni, illetve hogy ezek a könyvtárak egymás mellett tudjanak élni anélkül, hogy az egyik frissítése bolygatná a másikat.
Tulajdonképpen feltaláltad a konténert, mert ezzel egy program egzaktul meg tudja mondani, hogy ő milyen könyvtárakat használva szeretne futni és ezek egymás mellett tudjanak élni anélkül, hogy az egyik frissítése bolygatná a másikat.
Tulajdonképpen feltaláltad a tisztességes függőségkezelést, amit az oprendszereknek nem sikerült megugrani és ezért workaroundként konténerekkel kell megoldani.
- A hozzászóláshoz be kell jelentkezni
Tulajdonképpen feltaláltad a tisztességes függőségkezelést, amit az oprendszereknek nem sikerült megugrani és ezért workaroundként konténerekkel kell megoldani.
Továbbra se érted a konténerek lényegét...
- A hozzászóláshoz be kell jelentkezni
Az arányok nem stimmelnek, mert amit eddig 1 gépen/VM-ben futtattál, azt most divat szétszedni 15 konténerbe. Hogy aztán ez jó-e, és egyszerűbbé teszi-e az életet, azt döntse el mindenki maga. Meg hogy mindig jó-e, hogy nem tudsz egy egyszerű konfig paraméter változtatni, hanem az egész konténert újra kell csinálnod hozzá.
Persze ha LXC-zel, az más.
- A hozzászóláshoz be kell jelentkezni
Azt egy egyetlen icipici apróságot nem vetted észre az ábrán, hogy a container deployment alapvetően annyi változást okoz, hogy alkalmazásonként van erős szeparáció (nem tudják egymást zavarni) és nincs virtualizáció okozta overhead, ez utóbbira utal a "going back in time", mert K8s node tipikusan bare metal szerveren van. Az általad eszközölt "javítás" nettó faszság, abból ered, hogy nem érted a konténereket.
- A hozzászóláshoz be kell jelentkezni
Persze, persze. Nem értem. :D Te nem érted a virtualizációt. Mindegyiknek van helye, azt kijelenteni, hogy a konténer jobb mindenben is, nettó faszság. Az ábra, amit javítottam, meg egy marketing bullshit hülyéknek.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Persze, persze. Nem értem. :D
Minden jel erre mutat, hogy nem érted a konténereket, ezért írsz ilyen faszságokat: "Kirúgom onnan az op. rendszert és máris egyforma magad a két kupac."
Te nem érted a virtualizációt.
Aham. Most is szoktam még ajánlani bizonyos esetekben.
Mindegyiknek van helye, azt kijelenteni, hogy a konténer jobb mindenben is, nettó faszság.
Senki nem jelentette ki, hogy a konténer mindenben jobb. Az említett ábrán annyi van, hogy a K8s és a konténerek feleslegessé teszik a virtualizációt.
Az ábra, amit javítottam, meg egy marketing bullshit hülyéknek.
Hát igen, az ábra a javításoddal egy bullshit hülyéknek. :D
Tudod, nagy szerencse, hogy itt vagy nekünk te, akinek van kb. 0 közeli ismere a konténerek kapcsán, de leiskolázza a teljes IT világot, hogy faszságokat művel bullshit marketing alapján.
- A hozzászóláshoz be kell jelentkezni
Szokás szerint litániát írtál, a semmiről.
FYI: ma is éppen konténerekkel foglalkozom élesben. Meg virtualizációval. Élesben. Nem slide-okat mutogatok. :D
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Szokás szerint litániát írtál, a semmiről.
Tehetek én róla, hogy nem érted?
FYI: ma is éppen konténerekkel foglalkozom élesben.
Jah... én is, élesben is, csak én közben nem beszélek faszságokat. :D
- A hozzászóláshoz be kell jelentkezni
Valójában, sok mindent írtál, csak azt nem, hogy szerinted mi a faszsgág azon, hogy kihúztam egy op. rendszert onnan, ahonnan az teljesen felesleges :D :D :D
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Valójában, sok mindent írtál, csak azt nem, hogy szerinted mi a faszsgág azon, hogy kihúztam egy op. rendszert onnan, ahonnan az teljesen felesleges :D :D :D
Annyi, hogy egyrészt tipikusan nem olyan virtualizációt használsz, ahol ne lenne egy oprendszer a hypervisor alatt, másrészt azért, mert az a Kubernetes ábra nem arról szól, amiről írsz. Ezen túl a konténerben egy-egy alkalmazás fut, amit nem vettél eddig észre, ezért tűnik azonosnak számodra. Minden más stimmel.
- A hozzászóláshoz be kell jelentkezni
hogy egyrészt tipikusan nem olyan virtualizációt használsz, ahol ne lenne egy oprendszer a hypervisor alatt,
ROTFL
Ezt a kitételt azért hozod, hogy az ábra stimmeljen. Lófaszt nem. Én kizárólag Tier-1 virtualizációt használok, ahogy másik is.
Ezen túl a konténerben egy-egy alkalmazás fut, amit nem vettél eddig észre, ezért tűnik azonosnak számodra. Minden más stimmel.
No shit, Sherlock!
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Ezt a kitételt azért hozod, hogy az ábra stimmeljen. Lófaszt nem. Én kizárólag Tier-1 virtualizációt használok, ahogy másik is.
Hát, ez a marketing bullshit, hogy az Type-1 lenne, amit használsz, csak azért, mert egybe van csomagolva a hypervisor egy oprendszerrel... akkor a korábbi Type-1 - ami valóban hardverből futó virtualizáció - mostantól Type-0? :D
No shit, Sherlock!
Így megy ez. Feltelepült már a Docker?
- A hozzászóláshoz be kell jelentkezni
Aham, ismerem, ebben is szépen le van írva, hogy mi a vita a Type-1 és Type-2 kapcsán és miért erős marketing az, hogy egy hypervisor alá odacsomagolt OS az Type-1. Egy hardverbe integrált LPAR sokkal inkább Type-1, mint egy Linux kompatibilis kernel + nyílt forrású környezeten futó ESXi vagy egy Windows kernel és HAL felett futó Hyper-V.
- A hozzászóláshoz be kell jelentkezni
További olvasnivaló:
https://en.wikipedia.org/wiki/VMware_ESXi
Onnan, hogy:
VMware ESXi (formerly ESX) is an enterprise-class, type-1 hypervisor developed by VMware for deploying and serving virtual computers. As a type-1 hypervisor, ESXi is not a software application that is installed on an operating system (OS); instead, it includes and integrates vital OS components, such as a kernel.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Na, ez az a marketing bullshit, amiről értekezni próbáltál ("instead, it includes and integrates vital OS components"), össze van csomagolva az OS+hypervisor, az vitatott, hogy Type-1 hypervisor-e, mert a Type-1 tipikusan hardverből támogatott virtualizáció volt évtizedekig. Aztán jött a VMWare és deklarálta, hogy ő bizony Type-1, ugyan van alatta OS, de az nem telepíthető külön. Szóval ez továbbra is vitatott, de jó marketing bullshit.
- A hozzászóláshoz be kell jelentkezni
🤣
Széles körben terjesztetted már ezt az elméleted? Mit szóltak hozzá? Itt lenne az ideje átíratnod a Wikipedia szócikket is az elméletedre. 🤔
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Itt lenne az ideje átíratnod a Wikipedia szócikket is az elméletedre. 🤔
Ott már említették, hogy vitatott. Az ESXi saját oldalán meg azt írnak a marketingesek, amit csak elbír a papír.
- A hozzászóláshoz be kell jelentkezni
VMware ESXi (formerly ESX) is an enterprise-class, type-1 hypervisor developed by VMware for deploying and serving virtual computers. As a type-1 hypervisor, ESXi is not a software application that is installed on an operating system (OS);
Pontosan hol említették, hogy vitatott? ☝️
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Ez továbbra is az ESXi Wikipedia oldala, a generikus oldalt olvasd el inkább.
- A hozzászóláshoz be kell jelentkezni
:D :D :D
Vicces a terelésed, a generikus oldal generikusan beszél a dolgokról. Az ESXi-ről pontosan az ESXi szócikk beszél, ami szerint az ESXi egy Type-1 hypervisor. 🤷♂️
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Egyébként most tényleg tök komolyan kérdezve ha pl. az ESX -et type-1 -nek tekintjük, akkor abban az esetben, amikor semmilyen hypervisort se kell bootolnod mert firmware szinten működik azt milyen típusnak nevezzük? Illetve az Oracle akkor miért tekinti a VMware-t soft partitioning -nek a licencelésben?
Ez az egész type besorolás lényegében csak a x86 platformot fedi le. De na, azért nem csak az a architektúra létezik.
- A hozzászóláshoz be kell jelentkezni
Olyan dolgokról filozofálsz, amik nem léteznek. Mutass nekem egy hiteles forrást, ami az ESXi-t explitict nem Type-1-nek tekinti. Nem, ne az Oralce marketing/licencelési bullshitjeit.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Kérdezz meg bárkit... ööö... úgy értem, bárkit, aki számít. :D
- A hozzászóláshoz be kell jelentkezni
Kik lennének azok? Mármint, akik vitatják kb. az összes forrást, ami fellelhető. Beleértve a gyártó állításait?
Te vagy? Tovább?
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Miből gondolod, hogy VMWare állítása erről nem egy marketing bullshit, amikor saját állításuk szerint is van egy cél-OS a hypervisor alatt? :D
- A hozzászóláshoz be kell jelentkezni
Meg az IBM ... Fárasztó vagy. Hozz még egy embert, aki hajlandó veled a széllel szembe hugyozni.
Meg az Oracle ...
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Na várj, mire is gondolsz ami nem létezik?
A firmware szintű virtualizáció vagy a Oracle ilyen téren lévő licencepolitikája? Mert én ezeket említettem.
Én egy szóval se utaltam arra, hogy az ESXi -t bárki is ne tekintené annak. Inkább arra utaltam, hogy ez a egész type besorolás nem sokat ér mert csak a x86 világra lehet ráhúzni a leírtak alapján. Ebből adódóan mint kategorizálás szerintem hiányos, és azon gyártók, akik több platformon érdekeltek nem is különösebben foglalkoznak vele.
- A hozzászóláshoz be kell jelentkezni
Nézzük meg, hogy mit mond az IBM a hypervisor témában. Ha valami, akkor az IBM tudja mi:
https://www.ibm.com/topics/hypervisors
Type 1 vs. Type 2 hypervisors
There are two broad categories of hypervisors: Type 1 and Type 2.
Type 1 hypervisor
A Type 1 hypervisor runs directly on the underlying computer’s physical hardware, interacting directly with its CPU, memory, and physical storage. For this reason, Type 1 hypervisors are also referred to as bare-metal hypervisors. A Type 1 hypervisor takes the place of the host operating system.
Type 1 hypervisors are highly efficient because they have direct access to physical hardware. This also increases their security, because there is nothing in between them and the CPU that an attacker could compromise. But a Type 1 hypervisor often requires a separate management machine to administer different VMs and control the host hardware.
[...]
VMware hypervisors
VMware offers Type 1 and Type 2 hypervisors. Type 1 hypervisors include:
ESXi hypervisor. VMware ESXi (Elastic Sky X Integrated) is a Type 1 (or bare-metal) hypervisor targeting server virtualization in the data center. ESXi manages collections of VMware virtual machines.
🤷♂️
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Meg az Oracle:
https://docs.oracle.com/en/solutions/deploy-vmware-sddc-oci/understand-…
[...]
Understand Compute Architecture (vSphere and ESXi)
This layer of the solution provides Oracle Cloud Infrastructure bare metal DenseIO instances for running the VMware vSphere hypervisor, ESXi. VMware ESXi is an enterprise-class, Type 1 hypervisor that runs virtual machines (VMs).
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
És hogy a fun se maradjon ki, ChatGPT:
A VMware ESXi milyen típusú hypervisor?
ChatGPT:
A VMware ESXi egy Type-1 hypervisor.
A Type-1 hypervisorok, más néven bare-metal hypervisorok, közvetlenül a host rendszer hardverén futnak, így a virtuális gépek közvetlenül kommunikálhatnak a hardverrel. Ez jobb teljesítményt és megbízhatóságot biztosít, mint a Type-2 hypervisorok, amelyek egy meglévő operációs rendszerre épülnek, és extra késleltetést és potenciális konfliktusokat okozhatnak az alatta futó rendszerrel.
Ezzel szemben a Type-1 hypervisorok, mint a VMware ESXi, biztosítanak egy izoláltabb és biztonságosabb virtualizációs környezetet, amely ideális az üzleti és adatközponti felhasználásokhoz, ahol a megbízhatóság és a teljesítmény kritikus fontosságú.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Akkor Type-0 lesz a hardveres hypervisor... :D
- A hozzászóláshoz be kell jelentkezni
Nekem mindegy, hogy hogyan csűröd-csavarod, ettől még egy ESXi alá nem kerül operációs rendszer 🤷♂️
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Hát de van alatta OS, VMWare szerint is, van benne kernel, az mellett egy Linux absztrakciós réteg, hogy tudjon Linux driver-t behúzni, van core dump, purple death screen, benne olyan OS-szerű dolgokkal... persze, nevezhetjük úgy, hogy ez nem OS, de minden szempontból úgy viselkedik, mint egy OS, ami össze van csomagolva a hypervisor-ral. :D
- A hozzászóláshoz be kell jelentkezni
Semmilyen OS nincs alatta, pláne nem úgy, külön blokkban, ahogy azt a marketing kép a Kubernetesnél mutatta. Még ha próbálod is úgy hajlítani a dolgot, hogy van ott OS, akkor sem alatta, max. benne. Vagy ennyire süsü vagy, vagy életben nem telepítettél ESXi-t. Értem, hogy kellemetlen a világodnak, hogy valaki felhívja a figyelmet az ennyire átlátszó kamukra, de hát ez van ...
De, ha már ennyire erőlködsz, akkor érdekes, hogy abba nem mentél bele, hogy a kontérből hol az OS, amikor a legtöbb Docker huszár azzal kezdni, ha valamit akar is értelmeset kezdeni, hogy
docker pull alpine|ubuntu|whatever
:D :D :D
Na, kb. ennyit erről.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
akkor sem alatta, max. benne
Ja. :D
De, ha már ennyire erőlködsz, akkor érdekes, hogy abba nem mentél bele, hogy a kontérből hol az OS, amikor a legtöbb Docker huszár azzal kezdni, ha valamit akar is értelmeset kezdeni, hogy
Egyrészt kevés docker huszárt láttál, másrészt a Docker már elavult.
Na, kb. ennyit erről.
Bizony, erről ennyit.
- A hozzászóláshoz be kell jelentkezni
Semmit nem tudtál ide összehozni, azt ugye érzed? Az, hogy nem alatta van, hanem benne, az kurván egyszerűsíti a képet, annyira, hogy az egy blokk az ábrán. Vagy netán neked külön kellett valaha is az ESXi-ben levő "operációs rendszert" frissíteni? Nem. Az egy termék, neked azzal semmi dolgod. Tehát, a marketing ábrán az külön szerepeltetni, az egy ordas hazugság, de legjobb esetben is csak csúsztatás.
Ha pedig ezt az "operációs rendszert" feltüntetni szeretnéd akkor tüntesd fel a kontérek esetén is, mert ott is lehet ilyen "operációs rendszer".
🤷♂️
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Semmit nem tudtál ide összehozni, azt ugye érzed?
Én csak röhögni járok ide, azt ugye érzed? :D
Az, hogy nem alatta van, hanem benne, az kurván egyszerűsíti a képet, annyira, hogy az egy blokk az ábrán.
Hogyne. Ha a PC-vel jön a Windows, előre telepítve, az is egyszerűsíti a képet. :D
Vagy netán neked külön kellett valaha is az ESXi-ben levő "operációs rendszert" frissíteni? Nem. Az egy termék, neked azzal semmi dolgod. Tehát, a marketing ábrán az külön szerepeltetni, az egy ordas hazugság, de legjobb esetben is csak csúsztatás.
Értem, tehát a külön frissíthetőségtől számít egy összecsomagolt valami külön rendszernek? Ha az alkalmazásom alá odacsomagolok egy Linux-ot és csak egyben adok rá támogatást és frissítést, akkor már nincs is Linux az alkalmazásom alatt?
Ha pedig ezt az "operációs rendszert" feltüntetni szeretnéd akkor tüntesd fel a kontérek esetén is, mert ott is lehet ilyen "operációs rendszer".
Konténerek esetén nincs ilyen operációs rendszer, hanem az alkalmazás futtatásához feltétlenül szükséges libek vannak csak ott. Nem tudsz a host operációs rendszertől jelentősen eltérő konténert futtatni, a konténer nem virtualizáció.
- A hozzászóláshoz be kell jelentkezni
Én örülök, hogy röhögni jársz ide (mindig elmondod, de geci erőltetett), mert így van, akin tudok röhögni.
Értem, tehát a külön frissíthetőségtől számít egy összecsomagolt valami külön rendszernek?
Kurván nem mindegy üzemeltetési szempontból. Az, hogy te közben mire hokizol devopsengineerszakértőmegmondóemberoktatóként, az engem kurván nem érdekel.
Konténerek esetén nincs
ilyenoperációs rendszer, hanem az alkalmazás futtatásához
ROTFL
Many people do not realize that containers are really Linux. As such, Linux containers cannot run natively on macOS. Therefore, the containers must run in a Linux virtual machine (VM), and a Podman client interacts with that VM. This is in line with all solutions for running containers on macOS.
Bővítsd az ismereteid, bazmeg :D
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Kurván nem mindegy üzemeltetési szempontból.
Nem üzemeltetési szempont a kérdés, hanem hogy ha valami alatt ott egy OS és egybe van csomagolva a kettő, akkor van-e alatta OS.
Bővítsd az ismereteid, bazmeg :D
Itt pont az van leírva, amit írtam, bazmeg, csak nem érted még mindig az egészet. Kell egy operációs rendszer, hogy a konténer rajta futni tudjon, mert a konténer nem virtualizált környezet, hanem high level olyan, mint egy statikusan linkelt alkalmazás, ami minden függőséget és cuccot tartalmaz, ami a futásához kell, kivéve az operációs rendszert. Ha a konténerben lenne operációs rendszer, akkor nem kellene alatta egy konténerazonos operációs rendszernek lennie.
- A hozzászóláshoz be kell jelentkezni
Az ESXi alatt valóban nincs. Az egy más dolog, hogy azon elv alapján, hogy bármit amit bootolni kell egy gépen és a firmware réteg felett fut, azt tekinthetjük-e OS -nek? Mert akkor mondhatjuk akár a ESXi-re, hogy egy olyan OS, ami kernel szinten tartalmazza a virtualizációs képességet.
"As a type-1 hypervisor, ESXi is not a software application that is installed on an operating system (OS); instead, it includes and integrates vital OS components, such as a kernel."
Lényegi szempontból a konténerhez való viszonyításban pöcs mindegy milyen típusnak hívjuk. A lényeg az, hogy (x86 platformon) mindkét esetben fut egy kernel. Viszont a virtualizáció esetén még emulálni kell egy hw réteget még egy plusz kernellel. Ez mindenképpen overhead -et fog jelenteni ahhoz képest mint amikor egy kernel szint van.
- A hozzászóláshoz be kell jelentkezni
Persze. Gondosan és aprólékosan elemzed, hogy az ESXi-ben "OS komponensek" vannak. Konténerizációnál nincsenek? Pl. macOS-en hogyan futtatsz linuxos konténereket? Mi kell hozzá? 🤔
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Pl. macOS-en hogyan futtatsz linuxos konténereket? Mi kell hozzá? 🤔
Nativan sehogy. Virtualizálnod kell hozzá egy Linux operációs rendszert és azon tudod futtatni a konténereket. Vagy natív macOS konténereket használsz, de az csak macOS-en fog futni.
- A hozzászóláshoz be kell jelentkezni
HAHAHAHAH
Na, végül kibújt a szög a zsákból? Szakértőúr?
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Kibújt: fogalmad nincs arról, hogy mi a konténer. :D
- A hozzászóláshoz be kell jelentkezni
Jah, jól van konténer-huszárkám, menj, ülj fel a hype-train-re ... Ahogy a konténereknek, úgy a virtualizációnak is megvan a helye, de ha nem hiszed, gyere, beviszlek olyan helyekre, ahol röhögve zavarnak el a konténereiddel együtt.
Az a vicc, hogy fogalmad nincs a dolgokról és foggal-körömmel védsz egy szándékosan elbaszott marketing ábrát - ami meglepetés - a konténerekben utazó számára kedvezően van megrajzolva.
:D
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Nyilván, mindenki balfasz, aki K8s-t használ, csak te látsz át a szitán, hogy hype-train, bár csak a téma felszínét kapargatod. :D
- A hozzászóláshoz be kell jelentkezni
Tévedsz, én nem állítottam, hogy annak nincs létjogosultsága. Én arról beszélek, amit te meg néhányan csináltok. Hogy temetitek a virtualizációt, mintha annak már reszeltek volna. Mindezt féligazságok pufogtatásával.
Pedig koránt sincs így.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Én arról beszélek, amit te meg néhányan csináltok. Hogy temetitek a virtualizációt, mintha annak már reszeltek volna.
Hát pedig ez a helyzet, a virtualizáció igen jelentős része ezzel feleslegessé válik.
Pedig koránt sincs így.
Kérdés az, hogy mennyit látsz belőle, ami alapján ezt a következtetést levonod...
- A hozzászóláshoz be kell jelentkezni
🥱
Ha valaki csak internetes szolgáltatásokat lát és csak azzal foglalkozik, hajlamos el is hinni, hogy az egész IT internetes szolgáltatásokból áll. Te ennek mintapéldája vagy.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Nem, nem csak azt látok... :D
Az a helyzet, hogy a felületét kapargatod a témának és abból vonsz le sommás megállapításokat.
- A hozzászóláshoz be kell jelentkezni
Ja, te meg nem a felületét kapargatod, hanem vagy tudatlanságból, vagy csak balfaszságból (csak azért is ellent akarsz mondani) hajtasz hülyeségeket, természetesen úgy, hogy azok azt támasszák alá, amiben éppen utazol. Úgy tűnik, hogy Java expert után most éppen konténer evangelista lett az új szakirányod.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Én csak a flame miatt járok ide, tudod nagyon jól... :D
- A hozzászóláshoz be kell jelentkezni
" Illetve az Oracle akkor miért tekinti a VMware-t soft partitioning -nek a licencelésben?"
A válasz röviden: $$$ :D
- A hozzászóláshoz be kell jelentkezni
A sales és marketing bullshit sokszor felülcsapja a tiszta kategóriákat. :D
- A hozzászóláshoz be kell jelentkezni
Amin senki se* csodálkozik, ha ismeri az Oracle licencelési politikáját :D
(* aki az iparban fdolgozik)
trey @ gépház
- A hozzászóláshoz be kell jelentkezni