- Milyen házat vegyek?
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Azonnali fotós kérdések órája
- Bluetooth hangszórók
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Fujifilm X
- Vezetékes FEJhallgatók
- HP notebook topic
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
Új hozzászólás Aktív témák
-
#10079
Aethelstone
addikt
emvy
#10078
Aethelstone
addikt
Nem, mivel a penetrációt jól mutatja, hogy mekkora az igény. Ha nincs igény, nincs fejlesztő. Más oldalról ha belekezdek egy zöldmezősbe, rohadtul nem mindegy, hogy találok-e kompetenciát vagy a projekt első fele azzal telik, hogy kutatgatom a választott technológiát vagy kilóra veszek elérhető embereket a piacon
-
#10076
Aethelstone
addikt
emvy
#10070
Aethelstone
addikt
Ez mondjuk abban az esetben igaz, ha nincs családod. Mert ha van és el kell tartanod őket, marha nagy szerencse kell, hogy abból tartsd el őket, amit élvezel. Saját tapasztalat. Másrészt ha sok a feladat és változatos, Java-ban is élvezem, nem kell a joy faktort még Kotlinnal is spékelni
-
Csaby25
őstag
Az csak egy ember véleménye, többen is írtak a fórumon.
Pl.:
"The trap with kotlin is that most teaching aids target those moving from java, and on that basis continually assume a strong knowledge of java. It can be very frustrating to have concept explained in terms of java, requiring the reader to learn how the feature works in java before the instructions for kotlin make sense.There are now online courses that teach kotlin without any prior knowledge, but these tend to be very basic, as no programming knowledge at all is assumed. The biggest ‘missing link’ is the lack of exapnations of kotlin advanced features for programmers coming from any language other than java.
We have a project that we are planning to migrate sections, or perhaps even the entire project from python to kotlin. and are finding documentation a barrier. The support material for learning kotlin is at its worst for those who have already learnt advanced programming, but do not specifically know java.Realistically, if you do not know how to program, sadly currently the best advice is probably to learn java first. Next choice is just learn as you go with kotlin but be aware there is simple less learn to code material and much material for advanced concepts assumes java knowledge. Becoming proficient in a language other than currently may simply create significant frustration when bringing the skills learnt to kotlin, only to find the kotlin documentation specifically knowledge of each step in java a prerequisite for the kotlin documentation.
As kotlin matures, and a wide range of support emerges, the contradiction of a language that makes java redundant requiring programmers to learn java will fade to nothing."
-
-
floatr
veterán
Van persze sok olyan ember, akinek ettől lesz adrenalin. De te is általánosítasz kissé. Sokan a "nagyobb tapasztalatukkal" azért nem hajlandóak az újabb technológia irányába mozdulni, mert lusták, rugalmatlanok, nem fektetnek R&D-be, vagy kivárnak, amíg mindenki elmegy mellettük
Nyilván sokéves rendszereket nem ír újra jellemzően senki, bár több olyan ügyfelünk is van, akik már 10 éves rendszereknél nem a polírozgatáson gondolkoznak. A bedőlés emberi tényező, de nem is ez a lényeg. Nagyon elment az igény az új technológiák irányába zöldmezősök esetében, és senkit nem fog érdekelni, hogy mi a véleményed az igényekről
Nyilván ez igaz visszafelé is, ha szerinted pl. a mongo jobb lenne content managementre, elastic meg monitoringra, de az ügyfél baromira liferay/sql párti, de szerencsére ez kopik kifelé.(#10042) mobal semmi, nekem is tök jól fut rajta a shadow warrior
(#10046) mobal lényegében virtuális gépeket használsz konténerek helyett, ami eltérően viselkedhet a production környezethez képest. Mert az feltételezem, hogy nem windowsos docker a live.
Akkor inkább már VBox-ban ubuntu/debian és azon docker. -
M_AND_Ms
veterán
Komoly, nagyméretű projekteket egyszer kialakítanak egy akkori technológiával, majd utána azt karbantartják és funkciószinten tovább fejlesztik ill hibát javítanak. De semmiképp nem állnak neki csak azért újraírni, mert bejött valami újabb technológia. Azonban sokszor van, hogy egyszer csak találnak büdzsét, elkölteni való pénzt é akkor kitalálják, írjuk újra "korszerűre" - az ilyennek legtöbbször az a vége, hogy egy funkcióban szegényebb, kezelhetőségben rosszabb, de csillivillibb és papíron korszerűbb terméket alakítanak ki, amit a felhasználók a pokolba kívánnak, mert a régivel semmi baj nem volt.
Személy szerint több példát láttam kórházi, egészségügyi rendszerek ilyetén való átalakításra. Volt egy karakteres, de gyorsan használható letisztult felület, amit átraktak egy grafikus guira. 10-szer akkora hardver 10-ed akkora felhasználói sebesség, rengeteg hibázási lehetőséggel. Mindez rengeteg pénzbe, időbe és energiába került, az a eredmény, az előrelépés pedig 0. De..., új technológiákat használtak. Hurrá!Szerintem ez az új és újabb technológia kergetés egy rossz gyakorlat.
-
Drizzt
nagyúr
Pedig itt stimmel mind a két dolog: zöld mező és java EE(7). Amúgy nekem mint kívülállónak, segítsetek megérteni miért jobb a Spring pl. a Java EE7-nél. Mi az, amit nem lehet, vagy nagyon nyakatekerten megcsinálni Java EE7-ben, de Springben nagyon simán.
Ami problémám van a Java EE-vel, hogy nem sok hozzá a jó anyag, illetve tesztelés nagyon nehézkes. Ezekben feltételezem jobban áll a Spring.
-
bambano
titán
"Ez nem valasz -- ha nem akar hozzajarulni, akkor miert nem rugja ki az OpenJDK-n dolgozo fejlesztoit?": ha elolvastad volna a linket, ilyeneket olvashattál volna benne:
"az Oracle valamikor 2015 második felében de facto leállította a Java EE fejlesztését és a fejlesztőket más, stratégiailag fontosabb projektekre csoportosította át": ez, openjdk szemszögből nézve, egyenértékű a kirúgással."Az a baj, bambano, hogy fogalmad sincs az open source-rol csak hasznalni szeretned, de azt nem erted, hogy mitol mukodik (es mitol nem).": na végre, vala{k,m}i feldobta a napomat. ez legalább olyan súlyos ökörség, mint mikor le-sjw-ztek engem. ha gondolod, tárgyaljuk ki, de ne itt.
-
bambano
titán
"Persze, az Oracle rak bele a legtobb energiat": az oracle java területen jelenleg abba rak a legtöbb energiát, hogy kirázza a nyakából az egész kócerájt.
"Vicces modon az Oracle kozutalatnak orvend az OSS kozossegben, pedig az OSS egyik legfontosabb kontributora a Java miatt.": az oracle ezerrel dolgozik azon, hogy mindent kidobjon, amit a sunnal megvett. azt az egy dolgot meg, amit nem akart kidobni, tönkrevágta. így lett mariadb, így lett a staroffice-ből balhés openoffice/libreoffice fork, így tolta a levesbe az opensolarist. komoly esély van rá, hogy a sparc architektúrát is dobják, aminek a végén semmi nem marad a sunból. csak tudnám, mi a bánatos francnak vették meg...
-
A második kérdést úgy értettem, hogy az jó megoldás, hogy építek egy docker imaget, majd az imagen lefuttatom a tesztet és ha minden oké mehet is prodba.
Előbb fusson a teszt + akármi és utána készítsek imaget?
Egyáltalán mikor célszerű kreálni?
Nem tudom jobban körülírni!
mobal,
-
MrSealRD
veterán
Kotlin tudás annyira még nem fejlett. (De most szervezünk kis önképzőkört, hogy felhúzzuk.)
Egyébként semmi különösre nem gondoltam, csak most nem a feladathoz keresek eszközt, hanem szeretném leltárba venni a létező eszközöket. Ezek közül is azokat ami folyamtosa fejlesztés alatt van és várható, hogy túlél pár évet...
-
bambano
titán
"ha zavarnak a meglevo bugok, akkor hasznalj mast, de ha nem egy hosszutavo projekt": hosszútávú.
ha nem használok olyan környezetet (nem csak az ide-t ideértve, hanem az összes többi cuccot is), akkor belefuthatok abba, hogy a böngészők már nem képesek megjeleníteni, amit megcsináltam. Mint például a woodstockot nem kezelik az újabb netbeansek."java -jar myApp.jar": most vagy elkerülte a figyelmed, hogy webes cucc lenne, vagy komolyan gondoltad, de akkor vadásszak web konténert, adatbázis kezelő réteget, stb. ? ezt inkább kihagynám.
-
bambano
titán
"Netbeans nem lesz kevesbe hasznalhato attol, hogy kevesbe nepszeru.": ezt értem, csak a kérdés az, lesz-e, aki fejleszti, javítgatja a bugokat. mert a webjükön a release map szerint 2016. vége felé lenni kellett volna 8.2.1-esnek, de nincs. nem jött be az eclipse, de inkább a projekt elején váltanék, mint közben, ha muszáj.
ahhoz, amit csinálni kellene, szerintem nem kell ee.
"Spring vagy Dropwizard eseten nincs szukseg appszerverre, tehat nem kell se Glassfish, se WF.": és akkor min fogom futtatni? eddig glassfisht használtam, nem dobnám ki, ha nincs súlyos ellenérv.
-
togvau
senior tag
Én ilyet még nem láttam, csak azt hogy mánágereknek van egy büfé-ruhatár szak mellé nagy arcuk, pszichopatikus jellemzőik, félinformációkból "a szomszéd józsitól aki ismeri a testvérének a főnökének a fiát aki ért hozzá" tájékozódva, a divatos technológiákat nyomják keresztük "ha mások szeretik, nem lehet rossz"
-
togvau
senior tag
-
-
G.Zs.
senior tag
Adott egy feladat, amire keresem a megoldast. A feladat elemzesenel a csapat feltarja, hol lehetnek nagyobb problemak a megvalositasnal. A csapatbol minden egyes fejleszto keszit egy kutatast, esetleg egy technologiai demot, prezentalja a sajat megoldasat, es ervel, hogy szerinte az a technologia miert lenne jo valasztas a kulcsfontossagu problemak megoldasara. A csapat ezutan megvitatja a felmerult megoldasokat, es kivalasztja melyik a leghatekonyabb. Egyhangu dontes eseten ugye nincs mirol beszelni, az lesz amit mindenki akart. Ha nincs megegyezes, es sok megoldas johet szoba, akkor a legnagyobb tapasztalattal rendelkezo vezeto dont.
-
Lortech
addikt
Vagy TomEE, ha már...
mobal: egyszerűnek egyszerű, de csak egy servlet konténer, így nem alternatívája egy Java EE alkalmazásszervernek.
Amúgy a wildfly is tök egyszerű, alapból is, de elég jól testre is szabható, moduláris.
Productionben pedig leginkább ugyanazon kell futni, mint fejleszteni (persze lehet egy lightosabb profilon), különben tökönlövöd magad, Java EE kompatibilitás ide vagy oda. -
floatr
veterán
A design jó, hiszen a legjobb helyekről nyúlták
De viccet félretéve, leszámítva a Visual Basic-es feelinget, rendben van az alapelképzelés, de nem design-válságról beszélek, amiben most épp a java készül elporladni.(#9542) mobal az indokláson van a hangsúly, de kétségtelenül jobb, mintha pascaloznának. Szvsz most kotlinnal kéne indítani, amit személy szerint utálok -- már a neve is ellenérzést kelt bennem, dinoszaurusz vagyok, elismerem -- de látom a trendet.
-
M_AND_Ms
veterán
Jók ezek a kulcsszavak.
Gondoljátok a működő, évek alatt rengeteg tudást magukba építő alkalmazásokat lecserélik, csak mert új eszmék, új hangzatos nevek tűnnek fel?
Ugyan már!
Az egyik rendszer, amin dolgozok 2003-ban kezdte az életét. Vannak részek, amit újraírnánk, de nem a használatos technológia miatt. Egyszerűen okosabbak lettünk a kiszolgált üzleti területen és már jobb megoldásokat tudnánk kitalálni. -
floatr
veterán
Mérhető, ja. Win7 -> bubi 16.04 migráció nálam is kedvezett a liferay és tsainak, pedig még csak nem is erőltettem a dolgot. Máshogy gazdálkodik az erőforrásokkal, más bloatwarek vannak, más maga a runtime implementációja. Számomra nagy kérdés az is, hogy mivel fordítják a JDK/JRE natív részét. No meg persze az sem elhanyagolható, hogy fut-e antivirus/antimalware, ami windows-on már az alap installnál ott figyel; az is csillapítja a java eszeveszett száguldozását. Persze nem akarom a vitát ezzel gerjeszteni, de csak oda jutottam én is, hogy jobban jártam vele munkához.
-
-
nji
aktív tag
Nyilván nem tudok annyit fizetni, mint egy milliárdos árbevételű esetleg multinacionális fejlesztő cég, mivel magánszemély (tanuló) vagyok.
Gondoltam, hogy itt is vannak hozzám hasonló, de felsőbb éves és több tapasztalattal rendelkező tanulók, akik még nem keresnek semennyi "k-t", se "több százezer k-t" és nem olyan nagyképűek és leereszkednek a többi tanulóhoz (mivel ők is voltak kezdők), és mert kell nekik egy kis zsebpénz, amíg a tanulmányaikat végzik. Egy két kredites fos kis tárgy nem ér meg annyit, amennyi egy fejlesztő órabére. Akkor majd felveszem legközelebb a tárgyat 1 vagy két év múlva. Csak elég érdekes, hogy még a külföldi processing fórumon sem tudja leprogramozni senki ezt a három algoritmust. Egyáltalán ért valaki normálisan ehhez a programhoz ??? Vagy ezt nem használja senki ???? Már sok helyen kerestem kész programokat, de ezeket az algoritmusokat a gyakorlatban nem találom sehol. Magamtól meg nem tudom megírni. -
axioma
veterán
-
#74220800
törölt tag
Es ha mondjuk ez a fix fejléc (házi része):
Public class PriorityQueue<T extends Comparable<T>>
akkor ennek a constructor-javal lehet akar arraylistet is letrehozni?
valahogy igy:
public class PriorityQueue<T extends Comparable<T>> {
private ArrayList<T> queue;
private int maxElements;
public PriorityQueue(int maxElements){
this.maxElements = maxElements;
queue = new ArrayList<T>();
}Szóval a problémám az hogy a classom neve megyezeik( a feladat kiirasat be kell tartani...) a java collectionban levő egyik class nevével (PriorityQueue), akkor ez azt jelenti, hogy csak ennek megfelelő classot tudok letrehozni a classommal, vagy akarmit, mert a peldanyositasnal a standard class nevet felülirja, es azt csinalja vele amit en definialtam?
-
floatr
veterán
Ez az oracle hivatalos hitvallása. Nem olvastad? Most jöttek rá, hogy lehet h erre kéne koncentrálni, nem a SOAP-ot nyomni még ezerrel.
Amúgy kövezzetek meg, de én a REST-ből implementációból csak a service method regisztrációt, és a message convertert használom. Ez a GET/PUT/POST/DELETE annyira felesleges nekem
-
#9001
Aethelstone
addikt
emvy
#8999
Aethelstone
addikt
Ebben igazad van elvileg....viszont ha az embernek mákja van és nincsenek kurva nagy üresjáratok a munkájában, akkor nagyon nehéz kitekinteni, mivel a projektek jó eséllyel ugyanarra a kaptafára készülnek, nagyon ritkán adódik, hogy valami új technológiát, (svn--->git?
) vezetnek be. Ergó, pár év után simán el tudja magát ásni az ember, ha nem megy új helyre melózni. -
floatr
veterán
Elhiszem, hogy van olyan, akinek ez jobban bejön. Meg látom, hogy sokan ráizgultak a lambdára is, mert az megoldja minden problémájukat az életben
Nekem eddig a project lombok volt az egyik leghasznosabb(#8988) Cathfaern egy szavam se lenne, ha lenne egy olyan üzemmódja is, ami nem igényli a lokális repót. Bár csak ezért migrálni nem kezdenék akkor sem...
-
#8957
Aethelstone
addikt
emvy
#8956
Aethelstone
addikt
Nem éreztem még annak szükségét, hogy lokálisan legyenek ilyen dolgaim. Ergó, ismét oda lyukadunk ki, hogy feladatfüggő, hogy mit használ az ember, nincsenek abszolút jó vagy kevésbé jó eszközök.
Szerk: Másrészről SVN-el is lehet local repót csinálni, amit szinkronizálhatsz a remote repóval.
-
Cathfaern
nagyúr
Ezt az Git-es local repo dolgot én se tudtam megértetni az egyik fejlesztőcsapattal ahol be akartuk vezetni. Mert mindig jött, hogy de olyan nincs, hogy egy fejlesztő úgy dolgozik, hogy az nincs fent a szerveren. A dologban csak az volt a vicces, hogy ezt pont az a fejlesztési vezető mondogatta a leghangosabban akinek már veszett el 1,5 heti munkája amiatt, mert nem commitolt svn-en...
(és ennek ellenére is továbbra is notórius 2-3-4 naponta commitelő volt) -
#8950
Aethelstone
addikt
emvy
#8947
Aethelstone
addikt
Nem érzem, hogy releváns különbségek lennének a két rendszer (svn, git) között. Én dolgoztam nemzetközi projektben SVN alapokon és 4-5 fős, helyi csapatban is GIT-tel. Mindkettő használható volt, oda kellett figyelni a hülyeségeikre és minden flottul ment. Minden másra ott a Mastercard
-
floatr
veterán
Épp arra próbáltam rávilágítani, hogy nincsen olyan h nem "mások szeme előtt maszatolsz". Nem vagy kénytelen összevissza másolgatni, mert ha létezik olyan a projektben, ami vakvágány, kivezetett branch, akkor azt megfelelő archív helyre mozgatod a repoban. Aki gyors munka miatt marhaságot csinál, azon a GIT sem segít. Épp ezért mondom azt, hogy szvsz egy totális félreértés a GIT hypetrain, ami egy olyan forrásból indul ki, ami bizonyos körökben fel van magasztalva már-már hites meggyőződéssel, és ezért nézem rossz szemmel azt, amikor erről indítanak, mert többnyire (tisztelet a kivételnek persze) fogalmuk sincsen h miért, csak azt látják, hogy "mindenki GIT-et használ". Elég radikális vélemény, tudom, mert a hype-széllel szemben témázok.
-
floatr
veterán
Nekem meg nem irreleváns, mivel a GIT egy eszközt ad a kezedbe arra, hogy személyes maszatolást csinálj anélkül, hogy nyoma legyen. Local history gyakorlatilag a nullával egyenértékű, ha meg mindent betolsz két lépésben, akkor meg csak feleslegesen bontottad ketté a GIT révén a folyamatot. Mindegy, nem akartam nagyon vitába keveredni, de én csak a divatot látom ebben az egészben az esetek 90%ában.
-
floatr
veterán
Első körben tisztázzuk, hogy céges környezetben, céges fejlesztési policy-val nézem ezt az egészet. Nálam a GIT rögtön ott bukik meg, hogy localhost-on van (lehet) olyan munkád a céges projekten, aminek nincsen nyoma a céges/központi repóban. A branch létrehozása egy mozdulat, ha a céges projekteken bíbelődsz valamit, az nem saját kis mitymuty, tessék létrehozni egy branchet akár kísérleti jelleggel a központi repóban, egy hosting/rendszergazda/devops kollégának meg legyen az a dolga, hogy ennek a feltételeit megteremti.
Minden branch minőségbiztosítási okok miatt meg kell hogy legyen központilag, lefedve egy task management rendszerrel úgy, hogy bármikor bárki tudja folytatni, review-olni, vagy épp merge-ölni DEV/UAT/PROD környezetbe.
#8933) WonderCSabo a másolás egy logikai művelet. Ellentétben néhány más rendszerrel, SVN alatt nincsen olyan speciális művelet, hogy branch, mivel nincsen erős kötöttség arra vonatkozóan, hogy a repoban mit hova teszel. Branch-et úgy csinál, hogy egy másik branch (URL) adott állapotáról egy referenciát készít az új URL-en. Meg kell határoznod a saját workflow-dat, hogy milyen elnevezéseket és kötöttségeket használsz. Ez nyilván lehet az eredeti ajánlás szerinti is, bár az csak egy viszonylag egyszerű munkafolyamatra jó.
(#8937) Aethelstone rebase
-
floatr
veterán
Szerintem feature branchingre inkább való az SVN. Az kétségtelen, hogy programozó sejtekbe csoportosulva a GIT jobban skálázódhat, de finoman szólva nem ez határozta meg a felhasználási területeket egyetlen projektnél sem -- legalábbis nálunk.
(#8924) Lortech Tisztában vagyok vele, hogy a gradle irányába folyik még a Duna is, de egyelőre általános felhasználásra kicsit még kísérleti szaga van. Kell neki még egy kis idő, de hiánypótló az ANT után.
A GIT meg nyilván felhasználás kérdése, ha kell, akkor kell. Én viszont a GIT-tel vagyok úgy, hogy az utóbbi években kialakított workflow-t csak megnehezítené. Nemrég írtam egy scriptet is SVNhez, hogy még azzal se kelljen időt pocsékolni, hogy kattintgat az ember a branchek között, meg a history-ban merge előtt, nem sokból tartana GIT-re átírni, de csak a változtatás kedvéért teljesen feleslegesnek érzem a változtatást. Én inkább érzem arculati tényezőnek, mint valóban hasznos eszköznek. Kicsit olyan érzésem van vele kapcsolatban, mint amikor az ember összekötött kézzel akar úszni, hogy más is láthassa, hogy tud összekötött kézzel is úszni.
-
Akkor nem is kellett volna feltenni a jdk 1.8-at?
Viszont itt is foglalt az ALT+SHIFT+X... Szerencsére itt enged bill.kódra keresni:
Ki is iktattam, így már van kisebb, nagyobb jelem. Szokni kell (Pláne hogy eddig eclipse videókat néztem és tanulgattam. pl. sysout+CTRL+SPACE). Ugyanakkor az ALT+ENTER megoldás az osztályok importálására szimpatikusabb.) -
-
DarkByte
addikt
De ehhez konkrétan "érti is" hogy az egy Spring XML, vagy csak string egyezést néz? Mert a Find Usages még a property fájlokban is megtalálja az osztályt ha le van írva a teljes neve (sőt még szerintem anélkül is) és szerintem itt is csak ez történik. De fixme.
A NetBeans-ért pedig kár. Java-s pályafutásomat azzal kezdtem és nem volt az rossz.
A Spring Tool Suite miatt elpároltam egy idő után Eclipse-re, ennyi volt a bűne. Na meg hogy Groovy támogatása nem sok volt neki akkoriban, szerintem azóta sem változott ez.Amúgy itt off, de a napokban egészen meglepődtem hogy a C++17 fordító milyen optimalizált kódot tud csinálni.
[link] Jó, biztosan gyúrt erre az arc hogy direkt ilyen kód készüljön, ahogyan a végén egy ember rá is kérdezett hogy megnézi nagy production kódban hogyan szúrja ki, hogy miért csinált több gépi utasítást mint kellene. De azért csak pislogtam mint hal a szatyorban mikor láttam. -
#8602
fordfairlane
veterán
emvy
#8601
fordfairlane
veterán
Szomorú dolog ez. Mintha ezek a menedzselt kódok ennyi idő eltelte után sem lennének képesek beérni a natív alkalmazásokat ebben a tekintetben. Hiába a hardver fejlődése, SSD-k, satöbbi.
Persze lehet, hogy nem jó helyen tapogatózok, és nem a menedzselt kódbázis a lényeg, nekem valahogy mégis úgy tűnik, hogy itt az egyik fő választóvonal.
-
-
#8564
PumpkinSeed
addikt
emvy
#8561
PumpkinSeed
addikt
A docker microservice-kre jó, de nekünk nem csak az van, minden elszeparált konténerekben van, és amikor elkezdtük csinálni nem éreztük úgy, hogy a docker alkalmas lenne a productionon futó db szerver futtatására. Vegyíteni meg nem akartuk, hogy akkor kis docker, kis lxc, meg talán most még egy kis openshift.
-
#8560
PumpkinSeed
addikt
emvy
#8559
PumpkinSeed
addikt
Nekem két főbb problémám van a Docker-el. A CoW az egyik, ami jó, mert 200 konténer esetén nem kell 200 image-t letölteni, de ezzel szemben a konténer tud írni a host file system-re. A másik a hálózat, nem teljesen szabályozom én, és telenyomja az iptables táblámat mindennel. Ezzel szemben LXC alatt igaz, hogy ezt nekem kell megcsináljam, de akkor is úgy szabályozom ahogy én akarom. Ezenkívül a loggolás se úgy van megoldva ahogy egy normális rendszernél ugyanis szó szerint csákánnyal kell ütni, hogy kihányja a logokat. Ami tetőzi, hogy az egymásközötti kommunikációt linkeléssel lehet a legegyszerűbben megoldani, ami amúgy megnyitja a teljes container-t a host fele is. Most hirtelen csak ennyi jutott eszembe.
Mondjuk amilyen ütemben nyomják ki az új verziókat ezek már lehet nem léteznek, viszont annyit változtak 3 év alatt, hogy mi ezért is nem ezt hanem LXC-re kezdtünk építkezni. Stabilabb alapot ad a rendszernek szerintem.Amúgy bocs azt hittem a kérdésed csak költői volt a zárójel miatt.
Így már világos.
Én nem választok max javasolhatok. Meg támogatom az üzemeltetést, hogy a jelenlegi fejlesztői funkciók maradéktalanul átkerüljenek az új környezetbe.
És jó a kávé? 
A Spring Tool Suite miatt elpároltam egy idő után Eclipse-re, ennyi volt a bűne. Na meg hogy Groovy támogatása nem sok volt neki akkoriban, szerintem azóta sem változott ez.
Új hozzászólás Aktív témák
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Milyen okostelefont vegyek?
- Samsung Galaxy A53 5G - kevesebbet többért
- Milyen házat vegyek?
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Azonnali fotós kérdések órája
- Kerékpárosok, bringások ide!
- Nintendo Switch 2
- Okosóra és okoskiegészítő topik
- Nothing Phone (3a) és (3a) Pro - az ügyes meg sasszemű
- PlayStation 5
- További aktív témák...
- HP Elitebook Folio 9470M laptop (14/i7-G3/6GB/256SSD)
- LG 45GS95QX-B 45" ÍVELT OLED MLA WQHD 240HZ 0.03 MS GAMING MONITOR
- HP Zbook 15 laptop (15,6FHD/I7-G4MQ/16GB/128SSD/Nvidia2GB)
- Latitude 7450 14" FHD+ IPS Ultra 7 165H 32GB 1TB NVMe IR kam gar
- LG 45GR95QE-B Ívelt OLED 2K WQHD 240Hz, 0.03ms, NVIDIA G-Sync ,FreeSync Premium ,HDMI 2.1
- 129 - Lenovo Legion Pro 7 (16ARX8H) - AMD Ryzen 9 7945HX, RTX 4080
- BESZÁMÍTÁS! Microsoft XBOX Series S 512GB játékkonzol garanciával hibátlan működéssel
- BESZÁMÍTÁS! 1TB Western Digital SN850X NVMe SSD meghajtó garanciával hibátlan működéssel
- Samsung Galaxy A12 64GB, Kártyafüggetlen, 1 Év Garanciával
- Bomba ár! HP EliteBook 830 G5 - i5-8G I 8GB I 256GB SSD I 13,3" FHD I HDMI I Cam I W11 I Gari!
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged