Hirdetés
- Hogy is néznek ki a gépeink?
- Menekül a HEVC licencdíja elől a HP és a Dell
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- Hobby elektronika
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- AMD APU (AM4 és AM5) topik
- Milyen videókártyát?
- Azonnali informatikai kérdések órája
- Gaming notebook topik
- Milyen asztali (teljes vagy fél-) gépet vegyek?
-
PROHARDVER!
Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.
Új hozzászólás Aktív témák
-
inf3rno
nagyúr
válasz
bambano
#30171
üzenetére
Nem vagyok benne biztos, hogy erre az egészre van tényleges igény. Mármint egy irodában azért előbb vagy utóbb mindenkinek világossá válik, ha nem megy egy nyomtató, és a másikra kell küldeni a nyomtatni valót. Utána meg pár lépéssel több, de ideiglenesen belefér. Ha valami program nyomtat, akkor meg gondolom az is kap valami visszajelzést, hogy sikerült e a nyomtatás vagy nem. És ha nem, akkor megpróbálhatja a másik nyomtatóval.
Tulajdonképp amit akarsz az az, hogy egy bizonyos porthoz legyen kötve az IP cím. Ezt tudják bizonyos managed switch-ek elvileg. Ez is alátámasztja [link].
Lehet még elé tenni egy gépet, CUPS szervert rátenni, és arra kötni a nyomtatót, pl USB-vel és úgy nyomtatni. Viszont akkor tök felesleges hálózati nyomtatót tartani.
Ezen kívül jogkör nélkül nem hiszem, hogy bárki bele tud nyúlni abba, hogy melyik mac address melyik IP címet kapja. Max még azt lehet, hogy a hosts fájlba írsz bele egy programmal vagy DNS szervert használsz.
-
Frawly
veterán
válasz
bambano
#30111
üzenetére
Ezt nem tudtam, hogy az is ott van a kernelben. Akkor lehet kipróbálom azt is. Én eddig úgy tudtam, hogy a Xen-t külön fel kell telepíteni.
(#30112) inf3rno: ezt teljesen jól tudod. De ha már VM-ben próbálgat valaki, akkor valós szimulációként próbálkozzon, és maradjon a dedup, cow, tömörítés, mindenféle redundancia stb. bekapcsolva. Ahogy kikapcsolgatsz mindent, meg ilyen minimalista ideálkörnyezetben próbálkozol, az nem fogja visszaadni, amit majd a valóságban tapasztalsz.
-
Frawly
veterán
válasz
bambano
#30109
üzenetére
Nekem meg elsőnek a KVM. Xen csak akkor, ha nem akar valaki még host OS-t is telepíteni, meg konfigurálgatni. De teljesen jó a KVM, nem kell semmilyen extra virtualizációs szoftver, pláne nem fizetős. Ott a KVM a kernelben, azt lehet használni QEMU-ban, tökéletes kombináció ilyen tanulásra szánt VM-ekhez, még a VT-x, VT-d is támogatott benne, ha a gép is támogatja, akkor simán megy.
A Hyper-V-t kipróbáltam anno sima desktop Win10 Prof-on, 64 bitesen, 2. gen i7-es laptopon, hát, lomha, lassú fosch az egész, de a MS-tól nem is vártam mást. Akkora overheadje van, mint az állat (ThinkPad X220 i7-2620M + 16 GB RAM mellett próbáltam). Ezt max. az ellenségemnek ajánlanám. Ha Windowson akar valaki hobbi VM-ezni, akkor VirtualBox, ha az nem tűnik elég stabilnak a feladathoz, akkor VMware Workstation ingyenes verzió.
(#30106) Dißnäëß: de én pont azt mondom, hogy én nem fukarkodnék, ha már virtuális gép, főleg szerver (vagy nem szerver, de valami modern desktop OS), én alapból min. 4GB-ot adok neki RAM-nak, és min. 2 prociszálat. Ezeket emelem is, ha szükséges, mert nem fut kielégítő sebességgel. 1 szál, meg 1 GB RAM nevetséges, annyit max. ilyen retro Win9x-es virtuális gépnek adnék, esetleg WinNT4, Win2k-hoz, de már utóbbiakhoz is belőnék 2 szálat, mert tudják kezelni.
-
Frawly
veterán
válasz
bambano
#30099
üzenetére
Ja, hát ezek a legmodernebb 8-10 genesek már igen, mert az Intel érzi az AMD Ryzen konkurenciának a szorítását, és most bevetnek mindent, mert már nem élhetnek vissza az erőfölényükkel. Így most pakolják bele dögivel a legalsó kategóriás procikba is a sok magot, cache-t, hiányzó utasításkészleteket, hogy ne kelljen lehúzniuk a rolót. De szerintem ezek a modern i3-ak sem érik meg, mert hasonló árban vehetsz helyettük Ryzent.
De a szóban forgó 2-3. gennél még abszolút fölénye volt az Intelnek, és az i3-akból sok mindent letiltott.
-
-
#68216320
törölt tag
válasz
bambano
#30035
üzenetére
Nem tudom mit kellene figyelnem.
Valami log-ba nem kerül bele a sok boot üzenet? Akkor onnét kilesném.Csak azért gondoltam, mert samba másolásnál 80-85MB/s esetén az egyik cpu szálat szinte teljesen lefogja az smb.
Ezért jött rám egy kis para a cpu teljesítményt illetően. Ha ez maradni tudna már jó lenne. -
Dißnäëß
nagyúr
válasz
bambano
#29983
üzenetére
Szemeztem én is már ezzel szerelt lappal, de egyelőre okafogyottá vált, még mindig csak 1 gépen ülök. [link] Pár tavalyi és tavalyelőtti komment lentebb, linux érintettségű, akkor még azon kattogtak, hogy melyik disztróba kerül be támogatás és az milyen, illetve állítgatják páran, hogy jó a támogatása. Azóta ez csak javulhatott tovább, szerintem mint hardver, nemigen lehet gond vele, persze nem enterprise grade cucc, de otthon akár a külön szerelt kártyát, akár az alaplapra tett verziót akarjuk, simán behúznám ilyen itthoni célra, hogy akár egy drágább switch-el, akár direktben, összekössem az asztali fotó és video feldolgozó PC-m a pincében lévő NAS-al (ha nincs switch, direktben a két gépet, a többiek meg mehetnek a klasszik 1Gbit és wifi vonalon).
(Most hoztam is választ a kérdésedre, meg nem is, de inkább a megbízható ágra tippelnék, mint a vacakra).
-
inf3rno
nagyúr
válasz
bambano
#29941
üzenetére
Itt azt mondják, hogy jobb clusterben csinálni, mert egy gépnél hamar elfogy a memória és a processzor idő. [link]
Itt wireguard-ot ajánlják clusterbe, talán hasznos lehet: [link] Openconnect még amire azt mondták, hogy jobb, mint az OpenVPN, de azt már régebben olvastam, és kb. minden jobb annál az eddigiek alapján. Mondjuk a helyi kórházban attól még OpenVPN-el tolják valamiért, de lehet csak a kliens gépeken. Nem tudok sokat a témáról, de gondolom vannak szabványos megoldások, amik miatt sok VPN kliens kompatibilis sokféle VPN szerverrel...
-
F34R
nagyúr
válasz
bambano
#29932
üzenetére
Az nem FreeBSD-re van, tegnap meg homalyban voltam... ma eszembe jutott, OpenBSD-re csinaltak ilyet. de elvileg ez nem teljesen atvett systemd, csak ahhoz hasonlo inint rendszer.. [link]
FreeBSD-re egyebkent OpenRC aplikalhato.
En ilyen gepre nem tennek BSD-t.... Alpine -al probalkozhatsz, de inkabb Devuan..
-
inf3rno
nagyúr
válasz
bambano
#29932
üzenetére
Ja ezt néztem régebben, de nem kell komolyan venni szerintem, többek között azért sem, mert egy systemd fejlesztő mondja. Azok alapján, amit FreeBSD fórumon olvasok systemd-vel kapcsolatban kizártnak tartom, hogy bármi ilyesmit elfogadna a közösség. Nagyjából az az álláspont, hogy megnézik, és ha találnak bármi használható ötletet benne, azt esetleg belekódolják FreeBSD-be, de eddig nem tűnik úgy, hogy kifejezetten rajonganának bármiért is, ami benne van. A gummiboot-ot sajnálom, hogy benyelte az a fekete lyuk, úgy tűnik jó boot loader volt, de így, hogy már a systemd-sek határozzák meg a fejlesztés irányát, supportot, stb., jobb kukázni.
-
Frawly
veterán
válasz
bambano
#29926
üzenetére
Nem kizárt, hogy neked van igazad, de én erről nem tudok, mérmint hogy systemd-nek megfelelő szutykot tolnának a FreeBSD-sek a rendszerükbe. Valami linket tudsz erről adni?
(#29929) F34R: igen, ez meg a másik, hogy fájlrendszerek támogatása terén is le vannak maradva a BSD-k. Persze megértem őket, mert egy nagyságrenddel kisebb legalább a fejlesztők száma, de lehet van két nagyságrend is. Így meg a szűkös erőforrások nem elengedők ahhoz, hogy mindenben hozzák a linuxos támogatottsági szintet. Ezért van kevesebb tároló és mirror is hozzá. Viszont másik oldalról pont ez a jó is benne, hogy még nem támogatott minden sz@r rajta, meg nincs elbloatosítva.
-
Frawly
veterán
válasz
bambano
#29922
üzenetére
Sajnálattal olvasom én is. A FreeBSD nekem tartalék terv. Ami most még visszatart tőle, hogy a drivertámogatottsága erősen le van maradva a Linuxhoz képest (NetBSD még szimpatikusabb a még kisebb hardverigénye miatt, de az meg még rosszabbul át driverek terén), főleg GPU-knál meg Wi-Fi-nél problémásak a driverek, de amúgy mindenben le van maradva, ami driver, meg van pár szoftver, ami nem érhető el rá, pl. Wine, Steam. Na, meg mindenki kedvence, a systemd, pulseaudio sem érhető el rá., de ez pozitívum
![;]](//cdn.rios.hu/dl/s/v1.gif)
Meg amiatt sem BSD-zek még, mert még a Linuxban sem fejlődtem ki magam, nem használtam még ki minden benne rejlő potenciált. Úgy meg nem akarom elhamarkodottan dobni. De ha nagyon elbloatosodik a Linux, akkor elkerülhetetlen lesz a BSD-re váltás, a Win, MacOS nálam nem játszik.
A Debian éltetésével nem értek egyet. Bármelyik nagyobb, mainstream disztró felhúzható 10 perc alatt grafikus felülettel. Én az Archot 15 perc alatt felhúzom neked, ha nincsenek nagy extra igények, és valami sztenderdebb DE-vel telepítem, ami függőségnek beránt, megold minden szükséges dolgot.
-
Vladi
nagyúr
válasz
bambano
#29922
üzenetére
Tudtam én, hogy bepróbálod.
"beledugtam a debian telepítő pendrájvomat és 10 perc alatt lett."
Ugyan így voltam én a debiannal anno. Na most van egy olyan projekt, hogy itt kipróbálom, akkor honnan töltsem, meg mit, és hogy telepítek csomagot és hol a tároló és hol a centos 7 install lemezem...
"maradunk az "öreg vagyok én már bohócnak" szindrómánál"
"de szerintem a világ nem erre halad."
Jah hát nem erre. Viszont amerre, az neked ugyan úgy nem teccik mint ez. -
-
Vladi
nagyúr
válasz
bambano
#29836
üzenetére
"driver le. ez az én hibám."
Igen. A zártaknál ez alap, a nyílt drivereket le tudja kezelni.
"hallador kolléga pár napja publikált tűzfalas cikket"
Erről lemaradtam, illetve most se találom.
"ha nem romlott el, ne akard megjavítani"
1. mégiscsak elromlott, mert nekiálltál javítani.
2. ha mindenhez így állnánk, akkor még a fán ülnénk. Szerencsére elég sűrűn romlanak a dolgok."persze lehet ez a hozzáállás kifogásolható"
Igen.Ami a freebsd-t illeti, engem az lepett meg, hogy mennyire naprakész és bőséges a programkínálata.
Rád meg előbb utóbb vár a systemd-homed, esetleg ios rosszabb esetben windows. -
Vladi
nagyúr
válasz
bambano
#29830
üzenetére
Okés, vesézzünk. Én értem a problémádat technikailag és emberileg is, de:
2010 környékén 7600gt kártyámat az nvidia cseréltem 4670-re, az meg amd. ez az akkori fedorán úgy nézett ki, hogy driver le, fedora leáll, kártyát átszerel, fedora indul, driver betölt, kész.Ehhez képest a windows 7 ugyan ezen művelet alatt olyan összecsuklást produkált, kb amit imént leírtál.
A freebsd-s felvetéseidre nem tudok séróból válaszolni, de ha komolyan érdekel, biztos, hogy 10-15 perc alatt ki lehet gúglizni.
-
Frawly
veterán
válasz
bambano
#29824
üzenetére
Az RX570-nel nem tudsz mellényúlni. Melyik modellt vetted, 4 gigásat, 8 gigásat, Armor verziót? Ahogy nézem, 3 DP port is van rajtuk, úgyhogy paradicsomban fogod érezni magad. Ráadásul nem túl új kártya, a kernelben lévő amdgpu driver, és a linux-firmware csomagban lévő AMD firmware simán viszi, csak legyen fent a legújabb mesa is, akkor se X.org-os, se waylandes felületek alatt nem lesz gondod se a megjelenítéssel, se a hardveres gyorsítással, se a hardveres dekódolással.
Az RX570-ben még van annyi erő, hogy bármelyik játékot is simán elviszi 1080p 60 fps-sel, high beállításokon (néha médium, némelyik játékban az ultra is sima neki), Vulkan, DXVK, Proton is mind támogatott. Freesync is.
Ha nem játszol rajta, akár alul is feszelheted, underclockolhatod egy kicsit, azt mondjuk nem tudom Linux alatt hogy kell, de csendesebben jár majd tőle.
-
Vladi
nagyúr
válasz
bambano
#29825
üzenetére
"amikor kiderül, hogy minimum kernelt kellene upgradelni, hogy felismerje a kártyát"
Milyen kernel ez? Ez egy viszonylag régi gpu, nem elég modul?De rendes tőled, hogy nem a mianyánkat ki vagy a mennyekben.
singel userbe se bootolt? Vagyg ilyen csodák már nincsenek szisztemdés időkben?
mod: lesz egy kis időm megy fel a freebsd. Neked is javasom, vedd elő újra a projektet...
mod2:
amdgpu-pro dirver 18.40 már támogatja a kártyád, ez még centos 6-ra is elkészült. azt ne mond, hogy ennél régebbi a kerneled.
Meg 16-os ubuntura, az kb a debianod korabeli lehet, vagy régebbi.Értem, hogy kizártad magad, de hiányolok itt egy kis rtfm-et.
Vagy keresel csomit, de az már debian specifikus megoldás. -
-
Frawly
veterán
válasz
bambano
#29816
üzenetére
GT 1030 például. Esetleg GTX 1050. Ettől jobb felesleges is, mert mint írtad úgyse játszol. De fontold meg az AMD-t, annak jobb a drivertámogatottsága. Az NV kártyákhoz zárt NV driver kell, az AMD-ket meg viszi a kernelbe beépített nyílt driver.
Ami a jelentősebb megkötés, az a két DP port. Ilyen nem biztos, hogy minden kártyán lesz, ez szerintem gyártófüggő is, azaz NV-n belül is gyártója válogatja. DP szokott lenni majd minden kártyán, meg HDMI is, de hogy pont DP-ből legyen mindjárt kettő, annak nagyon utána kell nézni.
Az a kártya, amit most vettél, az konkrétan milyen? Milyen driverrel hajtod?
-
-
Frawly
veterán
válasz
bambano
#29787
üzenetére
Wow, ez nekem teljesen új. Nem tudom hogyan másol /dev/null-ba, mikor azon nincs fájlrendszer. Persze ettől még lehet megoldották. Azt sem értem, hogy ha egy fájllal tudja, akkor a több fájlnál mi okoz neki gondot. Valami directory-ra hivatkozik, de nem világos miért.
-
#79470961
törölt tag
válasz
bambano
#29688
üzenetére
Programozó, hogyne lenne nagy arca... Szerintem egy elavultan kezelt problémára adott egy új, jó, hatékony választ. Bughalmaz? És ha mindaz amit a szoftver tud, összeszeded egyes különálló komponensekből és kiegészíted saját scriptekkel mire nagyjából ugyanazt tudod hozni, mekkora lesz a kód és mekkora lesz a bughalmaz? Ha ebből élsz, és rengeteg munkaórát öltél enterprise környezetben sysv systemd migrálásra, bizonyára busásan megfizettek érte, egy egy erős win szituáció. De rajtam ne múljon, remélem a közösség hamarosan összefog a sötét nagyúr ellen, forkolja ördögi gyermekét, és a nap örökké ragyogni fog az új fork felett ami minden csorbát kiköszörül, hiszen mi is gátolna meg bárkit ebben?
-
kovaax
őstag
válasz
bambano
#29703
üzenetére
Sajnos a munkahelyi munkaállomásokon windows van, és úgy, hogy minden nap leállítom, másnap elindítom, az XP sp2 volt az első, amivel nem volt különösebb stabilitási problémám (az más kérdés, hogy egy csomó mindenben rám akarják erőltetni a f@szságaikat azóta is). Megkacsáztam, 2004 augusztus 25-én jött ki, kb. fél év után kaphattuk meg. Szóval addig stabilabb volt az otthoni linuxom...
-
Dißnäëß
nagyúr
válasz
bambano
#29703
üzenetére
Na jó, nem 24. 16-18 ? 96-ban Netscape navigátoroztam faternál a cégben és néztem a DOS után az űrtechnikát, utána jött egy ősrégi SUSE, amivel elkezdtem kapizsgálni egyáltalán, mi az a Linux, utána jöttek az első szopások VMWare-el, hát az ja, úgy kb. 2000-es évek első fele, pont gimi után. Akkoriban még jobban érdekelt az IT, mint a punci, érdekes módon.
-
samujózsi
senior tag
válasz
bambano
#29684
üzenetére
Nem csak szerinted, de pl a debian(?) fejlesztők szerint a noexec az hülyeség, úri huncutság, ördögi praktika...
De az is lehet, hogy ez már ubuntus marhaság: sok telepítő nem működik, ha noexec van a /tmp-n. És nem értem, hogy miért. (Úgy értem: miért oda csomagolja ki a futtatandó szemetet?) -
samujózsi
senior tag
válasz
bambano
#29626
üzenetére
Az bjztosan nem. A nested X gyakorlatilag ablakban futtat egy másik X szervert.
Nekemnmeg az kellene, hogy húzzon egy függőleges vonalat a monitor közepén és a két oldal önálló virtuális dekstopként viselkedjen.
Sokadjára megnézve lehet, hogy mégis nagyjából arról lenne szó, amit májmiki linkelt.Eredendően arra kellett volna, hogy az egyik oldalra kihajítom maximalizálva a böngészőt a szükséges doksikkal, a másik oldalon meg dolgozom, de úgy, hogy a munkafelület ablakai nem takarják el, nem mozdítják meg a browser ablakát.
Workarondként akár ez is szóba jöhet, bár macerás bizonyos esetekben: [link]
-
Dißnäëß
nagyúr
válasz
bambano
#29581
üzenetére
Nanana. Telco szektorban, de akár banknál is, vagy tkp bárhol, olyan irdatlan megagiga BSS stack-ek vannak Windows alapon, hogy nélkülük azonnal földbe állna az egész cirkusz. A vállalatirányítás csak 1 a listából, amit kiragadtál. Valid, de csak 1, az arányokat még így is eltolja bőven 20-30-50% körülre akár az, amikor jön egy csapat vendor egy kiírásra és röpködnek a négyjegyű CPU mag igények a proprietary cuccuk alá, amik miiiind-mind MS alapú megoldások. A vállalatirányítás Góliátja ezekhez képest szúnyogfing.
-
haddent
addikt
válasz
bambano
#29574
üzenetére
Szerintem arra gondolt a kolléga meg Linus is fregmentáció alatt, hogy csilliárd felé ágazott/ik a linux és "központi hatalomként" csak a kernel van, de ugye abból is forkolnak ide-oda mindent és semmi nem biztos, soha. Értem én, hogy sokszor szükséges a kalapálás-hegesztés egyedi módon, de 90% -ban ez a csakazértismáséssajátésegyedileszek
-
AcCEsS
senior tag
válasz
bambano
#29533
üzenetére
Tulajdonképpen a tv előtt ülve telefonról szeretnék átváltani Kodi-ról SteamLink-re. A kodi service leállítása simán működik, de sajnos Buster alatt a SteamLink kizárólag X környezetből futtatható, ezért előbb az X környezetet kell indítanom, azzal együtt autostartol SteamLink is. De időközben meglett a megoldás:
sudo usermod -a -G tty pi
sudo apt-get install xserver-xorg-legacy
Ez utóbbi a lényeg, és akkor már lesz /etc/X11/Xwrapper.config, amibe be lehet jegyezni az "allowed_users = anybody" sort.Így már simán működik!
-
Frawly
veterán
válasz
bambano
#29512
üzenetére
Ebben nem lennék biztos. Persze abban egyetértek, hogy lehet nem fizetődik ki a vele töltött munka, főleg nem egy cégnél. Bár ez attól függ, hogy ki mire használja.
Én hobbi szinten is gondoltam saját rendszerre, forráskódból forgatva. Ezt nem is disztrónak nevezném, mert akkor disztró valami, ha terjeszted. Én saját rendszernek tervezem, csak a saját használatra, csak saját gépre, csak azokat a progikat fordítani, amiket használok is, minden kifejezetten csak arra a gépre fordítva. Amúgy LFS-szerűen, de nem LFS-sel. Ez annyira egyedi rendszer lesz, ha tető alá is hozom valamikor, hogy senki másnak a gépére nem lesz alkalmas, de pont itt jön a poén, hogy nem is kell alkalmasnak lennie. Pont ez az, a legtöbb disztró keze meg van kötve, mert általános céllal mennie kell sok hardveren, illeszkednie kell sokféle felhasználáshoz. De saját célú rendszeren nincsenek ilyen kötöttségek, hogy Garázs Bt. gépén, meg Gipsz Jakab gépén is mennie kell. Emiatt kihagyhatok a rendszerből minden általam nem használt sallangot, a kernelbe már bele se kell forgatni egy csomó drivert meg szokásos lehetőséget.
-
haddent
addikt
válasz
bambano
#29512
üzenetére
Nem mindenki, csak nem tudunk róla, mert tényleg belsős. Ha jól tudom a Google -nél saját Debian forkot használnak saját hardeninggel. Ilyen méretű dolgokra gondoltam, ez alatt vicc kategória.
De ellenpéldának melóban van, hogy hozzák a teljes vm imaget aztán na tartsd karban a saját kis kiépített sles - saltstack világodban azt a szutyokszemét oracle linuxot oracle db -vel. Oracle nevet eleve meglátom már rosszul vagyok, annyi fertőt hoztak a világra
Borzalom minden amihez nyúlnak -
válasz
bambano
#29496
üzenetére
Az ilyen webes kódoktól a hideg is kiráz... Meg úgy a webfejlesztéstől alapvetően
(#29499) Frawly
tényleg csak arra lesz jó, hogy valaki megpróbálja jogászkodással a felelősséget áthárítani valaki másra Gyakran ez egy igen fontos szempont.
Szerintem a licenccel sincs probléma, főleg nem szerveren, mert a legtöbb szerveres dolog pont GPL-es opensource. Egy random rolling distrónál ki garantálja, hogy minden ami benne van jogilag jó? Egy normál distró esetén minden verzió adott, bármikor pontosan meg lehet mondani, hogy mit használunk, abban benne van-e egy adott rés stb.
-
haddent
addikt
válasz
bambano
#29496
üzenetére
Hát ezért vannak a webpack meg társai. Felszippantja az összes includeot, összegyúrja, minimize aztán ott van egyetlen (vagy több) saját kis js csomag. A fejlesztés további része, ha megszűnne egy csomag támogatottsága jó kérdés lenne, de ebbe ne menjünk bele, mert egyetértenénk, hogy a js mekkora egy undormány hányinger és itt nincsenek hozzászokva, hogy egyetértünk
-
samujózsi
senior tag
válasz
bambano
#29487
üzenetére
A 20.04-re kicsi az esély. A 16.04 kb így került a vasra, úgy egy héttel a megjelenése után, de csak kényszerből, mert a régebbi kernelekkel voltak gondok az akkor vadonatúj procin, ebben találtam olyan kernelt ami többé-kevésbé jól kezelte a hardvert.
Az új rendszerekben sok a bug, ezért is tartok kicsit a rolling release-ként megjelenőktől (arch, suse). -
Frawly
veterán
válasz
bambano
#29487
üzenetére
A várással nem értek egyet. Nincs értelme várni, ennyi erővel mindig várhatnánk valamire. Ha most kell OS a szerverre, akkor most kell, azt kell feltenni, ami már most megjelent. Egyébként pont ez is a rolling előnye, nem kell semmilyen kiadásra várni, meg külön disztrófrissítésekre időt dedikálni.
Egyébként meg attól is függ, hogy mekkora támogatottsági időt akar. Ha nagyon hosszú támogatottsági idő kell, akkor a CentOS 8.1 a legjobb jelenleg ebből a szrmponból, az 11 és fél évig támogatott lesz még, ennyi év után meg nem az lesz a szempont, hogy a telepített rendszer elavul (mert az el fog már 2-5 év után avulni nagyon csúnyán, a régi verziók nem fogják tudni semmi újabb szoftvernél kielégíteni a verziófüggőséget), hanem a gép hardverügyileg is teljesen elavultnak fog számítani addigra. Vagyis vannak ennél hosszabb támogatású disztrók is, de azok már fizetősek tudtommal.
-
-
haddent
addikt
válasz
bambano
#29443
üzenetére
Nem, ezen valóban nem lehet vitatkozni, mert pontosan gépi feldolgozás szempontból tulajdonképpen zseniális, de visszamehetünk teljesen elemi, matematikai feldolgozásra, azazl formális nyelvek és automatákra, nagyon szép, egyszerű, lineáris determinisztikus automatával felismerhető nyelv. A CSV már ott egy rakás szar, hogy nincs konkrét szabvány, de ha ezt félretesszük és jóhiszeműen feltételezzük, hogy mindenki a nevében szereplő comma -t használja, akkor is egy káosz egy json/yaml -hez képest. Ez nem szubjektivitás kérdése egész egyszerűen.
Ha esetleg netán elírtad volna és pont fordítva értetted, tehát, hogy "humán" szemszögből ronda, akkor elnézést a "kirohanásért", ehhez a véleményedhez nyilván tökre jogod van
Vagy megint elmehetünk olyan irányba, hogy nagyon végtelenül primitív egyszerű adat (struktúrának nem nevezhető) kis szösszeneteket ki lehet fosni csv -ben is, csak akkor meg elő fog jönni az a tipikus eset, amikor pl. syslog esetén nem az RFC szabvány szerint logol valaki/mi, "me' megspórolunk 3 bitet!" aztán amikor valaki parsolni, értelmezni, aggregálni, rendszerezni szeretné (pl ELK, Graylog) akkor majd írjon magának hozzá egyedi lószart, vagy töltsön le plugint, nem ám 1 kattintás a szabvány szerinti
-
inf3rno
nagyúr
válasz
bambano
#29420
üzenetére
"mondtam én, hogy * nem szabványos formátum? hint: nem mondtam." (*: a JSON)
"Monitoring adatokat pont, hogy igenis valamilyen sztenderdizált formátumban és azon belül is szépen formázva adunk ki,: vagyis csv-ben, és még véletlenül sem json-ben."
Egy kicsit önellentmondóak a hozzászólásaid.
-
haddent
addikt
válasz
bambano
#29405
üzenetére
Igen, előfordul, nem egyszer. Ahogy az is, hogy fej-fej megy a C -vel. Java meg hasonló viccek közelébe nincs soha. Nyilván amint olyan részhez érünk, ahol nem a C libeket használja, hanem pure python, akkor nagyságrendekkel lassabb, nem hittérítés részemről továbbra sem
bambano persze, ha bios -t vagy hasonlót fejlesztünk. De akár már csak kernelnél is inkább kell gondolni arra, hogy ez nem 1x megírom és 30 évig nem nyúlok hozzá majd újraírom lesz, hanem délután jön 2 másik mikrokód amiket integrálok, commit, CI tesztek stb aztán deploy meg testing aztán production. Fenntarthatóság, követhetőség. Persze mindezt ésszel, vannak helyek ahova aki nem sima C -t használ fejbe kéne lőni
-
samujózsi
senior tag
válasz
bambano
#29407
üzenetére
Épp ezért nem fogok grep/sed helyett pythont használni, ellenben perl-t azt bármikor, ha az előbbiekkel nem lehet két mozdulattal elintézni vagy épp lehet, csak kib.lassú... (pár hónapja futottam ilyenbe, hogy sorokban stringet cserélni bizonyos esetekben nagyságrendekkel lassúbb a grep ... | sed -e ... formában, mint perl szkriptben. (Konkrétumokra nem emlékszem, talán a notebookomon megvan valahol, ha kell)
-
samujózsi
senior tag
válasz
bambano
#29405
üzenetére
Az nem bash, már bocs... egyébként van amikor gyorsabb a futása, mert a sed és a python más regex feldolgozót használnak.
Te itt foggal-körömmel véded az álláspontod, hogy bash, most meg kiderül, hogy valójában nem is a bash a lényeg, hanem a unix/linux toolok használata? (Amit viszont természetes, hogy meg kell ismerni annak, aki dolgozni akar a linuxszal) -
-
samujózsi
senior tag
válasz
bambano
#29399
üzenetére
????
Na ezt részletezd plíz, mert a "nemszabvány" csv ugye úgy néz ki, hogy egy sor = egy rekord, a mezők általában ;-vel (vagy más megadott karakterrel) szeparálva, plusz lehetőség van a mező tartalmának idézőjelezésére, hogy el legyen különítve a numerikus és a string adat (illetve ha a mező tartalmaz a szeparátorral azonos karaktert, akkor ott ne akarjon új mezőt a parser)
Ha valami egyedit csinálsz, annak már csak az általad adott neve csv. Szerintem. -
samujózsi
senior tag
válasz
bambano
#29394
üzenetére
Itt szokott előjönni (mármint a csv vs egyéb formátum témában), hogy
- azért mostanában elég ritka, ha egy fejlesztő csapat egy konkrét cég házi csapata, soha, senki másnak nem dolgoznak. Az jellemzőbb, hogy külsősök, saját kódbázissal x darab jelenlegi és y potenciális, jövőbeni ügyféllel. Emiatt akkor is muszáj univerzális megoldással jönniük, ha konkrétan nektek dolgoznak.
- írj korrekt csv parsert shellben! (+1: minek, ha van készen más script nyelven?) -
haddent
addikt
válasz
bambano
#29388
üzenetére
Ebből a kommentedből is látszik, hogy nagyon más nézetet vallasz. Nem rossz vagy jó kérdése ez és nincs igazad meg nekem sem, továbbra is mindkettő kell. Egy modern, nagy, bővülő, naponta 10x commit-test-deploy ci óriás enterprise szörnyet a te módszereiddel borzalom lenne életbentartani, vagy inkább lehetetlen.
Pont a példád a tökéletes példa. Monitoring adatokat pont, hogy igenis valamilyen sztenderdizált formátumban és azon belül is szépen formázva adunk ki, hogy univerzális és kompatibilis legyen ne csak a te shell scripteddel, hanem grayloggal, prometheussal, kibanával meg nagyjából bármivel is, ne kelljen külön parser meg interpreter hozzá. A json beolvasása objektummá ami aztán iszonyú jól kezelhető pontosan 2 sor (melyből az egyik 1 import) Pythonban. Nincs elírás, nincs jajj idézőjel, space, nincs fájl ellenőrzés mert ez mind a beolvasó object exception modelljeinek része. Egyszerű, elegáns és nem utolsó sorban gyorsabb/hatékonyabb is mint a bash valószínűleg, mert egy agyonoptimalizált C kód-wrapper
A hálózati példád nem fejtetted ki ennyire, de vakon erről is kb. ez mondható el. Lehet iptables írogatni vimmel, csak aztán azt tartsa karban meg egyben aki nem normális.. Akár csak egy Vyos vagy pfSense sem tesz rá túl óriási absztrakciót, de épp akkorát, hogy át tudsz látni 1000 szabályt is.
Viszont van az a hely, pl. pont a kígyó saját farkába harap, Pythont nem lehet Pythonban fejleszteni, mert egy fos lesz. C -ben kell
Nem az absztrakció az ellenség.. nem hülyegyerekek találták ki ezeket és nem hülyegyerekek számára. Akkor van óriási probléma, amikor a hülyegyerek él az absztrakció nyújtotta lehetőségekkel és kényelmi funkciókkal úgy, hogy fingja nincs róla mi zajlik a háttérben. Na az k*#& gáz, és sajnos ebben viszont igazad van, hogy ez a többség. De nem a puska a hibás, ha lelőnek vele valakit..
-
samujózsi
senior tag
válasz
bambano
#29388
üzenetére
Én flame helyett maradnék a tények mezején.
Te gyűlölöd. Én tudomásul veszem, hogy ilyen és használom.
Ha valaki tanulni akar, annak szvsz nem azt kellene néznie, hogy egy szarrá hardeningelt/hackelt szerveren milyen lehetőségei vannak, hanem azt, hogy a tanulmányait befejezve, a témában kezdőként, milyen tudással tud elhelyezkedni, ha ez a célja.
Itt azért a bash elég sokadlagos szempontnak tűnik.
Linuxon ugyan default többnyire a bash, de rengeteg helyen futhat ksh-ba (*BSD), ash/dash/busybox shellbe stb.
Ezekből talán több van, mint kiherélt szerverekből. Unixból még nem láttam olyat, ahol ne lett volna perl felrakva, bár azt meg nem mondom, hogy mely unixon, melyik rendszerkomponensek íródtak perlben, valahogy a *bin könyvtárakban sohasem kerestem szkripteket, linuxon is tudom, hogy sok rendszeralkatrész (igaz, főleg GUI-s) íródott pythonban, de ezekre is igaz: tudom, hogy vannak, emiatt nagyon ritka, ha a python alap nincs fenn.Ui: vicces, a git ragaszkodik a perlhez?
ubuntu18.04 serveren ezt mondja -
haddent
addikt
válasz
bambano
#29381
üzenetére
Miért, Pythonban megfordult a menetirány meg az ifirány, vagy miről maradtam le? Vagy a generátorokra gondolsz, amikkel 1 sorban rendezel le egy 50 soros C headert?
Az indentálást syntax részévé tenni szerintem fura, de jó ötlet, szerinted szar. A végeredmény szerencsére az, hogy még a kókánygenyó indiánus "programozók" kódja is valamelyest olvasható, néha -
samujózsi
senior tag
-
samujózsi
senior tag
válasz
bambano
#29376
üzenetére
Hurrá... írtam féloldalnyi választ, majd a mobil "back" gombjával sikeresen eltüntettem.
Nem írom újra: az általános shell ismeret kötelező, a bash-t... nem vinném túlzásba. Napi munka során nem nagyon fut össze olyan rendszerrel az ember, ahol nincs perl és/vagy python, esetleg awk.
Olyannal inkább, ahol bash nincs. Pl. beágyazott rendszerek, routerek (busybox)
Persze ez csak azbén véleményem.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- BESZÁMÍTÁS! Dell Latitude 3530 üzleti notebook - i5 1235U 8GB DDR4 512GB SSD Intel Iris Xe WIN11
- Hordozható napelem 10 Watt / 12 hó jótállás
- Sony WH-1000XM5 zajszűrős fejhallgató
- Bomba ár! HP Revolve 810 G2 - i5-G4 I 8GB I 180GB SSD I 11,6" HD Touch I Cam I W10 I Garancia
- Apple iMac 19.2 i5-8500 Radeon Pro 560X 4GB 16GB 256GB SSD 21.5" 4K Retina
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: BroadBit Hungary Kft.
Város: Budakeszi