A legidegesítőbb fősodratú idealizmusok

...töredékes listája

C++
uefi
cmake
docker
systemd
gnome3
ACL
dbus
cgroups

SELinux

Hozzászólások

Szerkesztve: 2020. 08. 14., p - 22:19

+pkg_config
+Python based build systems (meson, ninja, whatever...)

Sz*rk: A jávaszkriptet hogy hagyhattam ki, pedig talán az a legrosszabb az összes közül...
Sz*rk #2: B+, GTK3, az is...

Egyedul a C++-t szeretnem levenni a listarol.

Helyette feltennem az Electront.

Szerkesztve: 2020. 08. 14., p - 20:14

A dockerrel mi a baj?

(és miért használod a hypeolt/lassú/instabil/bloated/rossz helyett az idealizmus szót?)

A többivel egyetértek, a listához a NetworkManager-t hozzáfűzném még.

Psszt, elárulom az IP-címemet: 192.168.0.14

Meg ha a VM kivaltasara hasznalnak - az a jobbik eset.

Legtobben annak a hianyossagnak a potlasara hasznaljak, hogy meg a Unixos fajlrendszer alapjait se ertik, ahogy a TCP portok alapjait sem. Meg sem fordul a fejukben, hogy a Makefile-ban a /opt-ba prefixelve is lehet egy szoftverbol 3 kulonbozo verziot leforditani, es kulon portokon hallgatasra konfigolni, hogy mind tudjon mas szerverekkel kommunikalni. Nem, ok ezt ujrafeltalaljak, es kenytelenek megerteni emiatt egy teljesen uj, fajlrendszernel sokkal logikatlanabb hierarchiat, amiben a legtobben azt se tudjak, epp mikor hany image fut, es kb hanyat tarol a gepuk. Aztan 5-en debuggolnak egy hibauzenetet a local copy-jukban. A te korosztalyod szepen telepakolta a /opt-ot, ezeknek a fiatal suhancoknak meg minden kulon projekt egy uj Docker instance es nem ertik miert fogy ki a RAM olyan kurva gyorsan a gepbol, meg hogy amig sleepelt a gep, miert kavarodott meg a guest oraja.

Hasznalom evek ota, de csak mert muszaj, es mert a CI-t is igy a legkonnyebb hozzakapcsolni posztmodern "idealista" cloudeknal. Megtanultam, mert muszaj voltam, de nem szeretem. Cloudban oke, sot, muszaj hasznalni, de lokal copy-ban csak akkor nyitom meg, ha felmerul a gyanu, hogy valami amiatt mukodne maskepp (beigazolodni nagyon ritkan szokott).

Meg sem fordul a fejukben, hogy a Makefile-ban a /opt-ba prefixelve is lehet egy szoftverbol 3 kulonbozo verziot leforditani, es kulon portokon hallgatasra konfigolni, hogy mind tudjon mas szerverekkel kommunikalni.

Lehet igen, de ha a 3 különböző verzió ezen felül különböző 3rd party libeket is igényel, akkor azokat is külön-külön kell fordítani, illetve a libek által igényel libeket is, stb. Lehet persze a dockert is olyanra használni, amire nagyon nem kéne, valószínűleg ez történt a kollégáid esetében. De van pár alkalmazási terület, ahol viszonyt elég hatékony/kényelmes. Pl. egy Python webes app: nem kell szórakozni a rendszer (valszeg elavult) Python verziójával, hiszen ott a konténerben, ezen felül az összes 3rd party Python modul is, + adatbázis, + Redis, + task-scheduler, + reverse-proxy webszerver, stb. Emellett könnyebb megoldani egy load balancer mögött a skálázódást is.

"Pl. egy Python webes app: nem kell szórakozni a rendszer (valszeg elavult) Python verziójával"

conda - home konyvtaradba telepul es minden python cuccbol, de meg python verziobol is olyanod van, amilyet akarsz.

Docker erre a kerdeskorre is overkill.

De ha a conda-t nem is ismerem, akkor se nehez /opt-ba python-t forditani.

Nem csak Pythonról volt szó, hanem mellette még több elemről, amiket külön-külön telepíteni/fordítani kell. Dockerrel kiválasztod melyik verzió kell az adott szoftverből, oszt annyi. Emellett megoldja többnyire azt a problémát is, hogy a fejlesztői környezet eltér a szerverétől, így kevesebb a "nálam működött" típusú probléma.

Hany olyat lattam, ahol a felrakott biztonsagi frissitesek meglete azon mulott, hogy mikor futott le a docker build... ha az adott distrobeli fix utan, akkor fent volt, amugy nem. Igy a distro fix elott deployolt microservice-eknek nem volt meg a security fix: mert image buildkor - ami rogton deploy idejen tortenik - volt az utolso $PACKAGE_MANAGER update-je.

Ilyen esetben inkabb yool segit a sysadminnak masra mutogatni. :)

De tovabbra is inkabb azt tartom eretneksegnek, ahogy nehanyan a local copy-jukban hasznaljak mindenre is a dockert.

Arra azért jó a docker hogy a rendes OS-ed megmaszatolása nélkül, büntetlenül tudsz tesztelni, próbálgatni végtelen sok alkalmazást, amiket úgy el tudsz utána távolítani, mintha sosem lettek volna ott. Illetve más esetekre is jó, ha pl nekem gyorsan kell egy local postgresql tesztelni, fejleszteni valamit, akkor nem telepítem fel a csomagkezelővel, hanem mondok egy docker-compose up -ot ennél a fájlnál:

[gyuszi@gyuszidev postgres]$ cat docker-compose.yml 
version: '2'

services:
  postgresql:
    image: 'docker.io/bitnami/postgresql:11-debian-10'
    ports:
      - '5432:5432'
    environment:
      - 'ALLOW_EMPTY_PASSWORD=yes

És már megy is. Amikor meg már nem kell, kigyakom a francba.

"egy uj Docker instance es nem ertik miert fogy ki a RAM olyan kurva gyorsan a gepbol, meg hogy amig sleepelt a gep, miert kavarodott meg a guest oraja."

Nem fogyaszt több RAM-ot a Dockerből futtatott Postgres mint a sima, mert ez nem virtualizált környezet, csak resource isolation van. Az órát meg egyáltalán nem értem.

Ha már ennyire vágod ezt a témát, akkor tudnál írni pár sort, hogy ez miért jobb, mint a FreeBSD jail? Félre ne érts, nem trollkodás, tényleg érdekel, miben nyújt többet.

(Nem értek annyira a jail-ekhez sem, csak amikor elkezdett a konténerezés divatba jönni, rögtön a jail ugrott be.)

Másra van. Docker fő előnye nem ott van, ahol 1-2 konténert kell futtatni, hanem ahol esetenként több tizet-százat, ugyanabból, esetenként skálázódva fel-le. Jail az inkább arra van, hogy egy adott rendszeren építsd fel magadnak a szeparált környezetet (persze, ezt is lehet automatizálni különféle módokon, akár cloud scale is, pl. Ansible, Terraform, stb.), míg a docker arra van kitalálva, hogy csináld meg egyszer a konténered, aztán azt terjeszd mint egy csomag. További előnye ennek, hogy azt előre tudod tesztelni, ha felhúzol még pár instancet a konténeredből (teszem azt skálázol felfele valamilyen workerből), akkor nagyjából biztos lehetsz, hogy ugyanaz fog ott futni.

Docker előnye nem önmagában jön ki egy gépen, hanem, amikor van hozzá valami orchestrator ami skálázza a cloudban, gépek között, stb. (Ez esetenként elég sok különféle komponenst is jelenthet). Gyuszk példája, hogy felhúz egy ideiglenes PostgreSQL-t, az inkább az "erre is jó" példája, mint a fő feladatköre. Pl. adatbázist vagy olyat, ami adatot perzisztál pont nem dockerből szerencsés futtatni. Vagy legalábbis az adat ne dockeren belül legyen :)

Persze, nem muszáj cloudban gondolkodni, kisebb környezetben is van haszna, akár egy gépen is: szépen berakod az alkalmazásod komponenseit, aztán a letesztelt csomag úgy ahogy van települhet ki automatizálva a devről a testing, prod környezetre.

Így van, ez egy "erre is jó" dolog volt, és valóban, perzisztens/fontos adatot nem tartunk a konténer belső fájlrendszerében, mert azt ha nem figyelünk egy kicsit, könnyen eltüntethetjük. Az ilyen local postgres -eket általában 1-2 napig használom csak valami fejlesztős-tesztadatos dologra, ezért nem foglalkozom vele hogy veszik-e vagy sem.

A dockernek van beépített human+machine readable inputja, amit percek alatt megírsz, lebuildelsz és futtatsz (Dockerfile), illetve tudsz terjeszteni (intézményen belül vagy publikusan akár).

A jail esetén azt hiszem csak 3rd party automatizmusok vannak, és valószínűleg az "ecosystem" hiányzik vagy nehézkes. Tehát ha összepattitasz valami hasznos konténert, amit mások is használnának, azt nem tudod ilyen könnyen átadni másoknak. Plusz az is igaz, amit sax írt.

Persze, mindent össze lehet tákolni néhány soros scriptben, csak ugye attól az még nem lesz egy ipari standard.

Ezzel az erővel minek git, hiszen össze lehet tákolni néhány soros scriptben is :)

Mondjuk ott van még olyan, mint az Ansible meg a Terraform, de lehet elbeszélünk egymás mellett, hogy mit értesz környezet alatt.

A cím rossz. Helyesen: a legidegesítőbb dolgok, amit NevemTeve olvtárs nem képes/akar megérteni/megtanulni/elfogadni.

Nem a kedvencem a kollega, de tok igaza van.

A posztmodern IT-ban amit nem lehet 5 perc alatt annyira elmagyarazni egy seniornak, hogy utana tudja, hol talalja a megoldast, az rossz technologia. Pont. Ez a fentebbiekre mindre igaz. Csak a C++ azert kivetel, mert az alapmuveltseg.

Maradjunk annyiban, a C++ a „szürke zóna”. Én is gondolkodtam rajta, oda való-e, de tulajdonképpen IGEN, oda való, mert mindent meg lehet írni sima C-ben is, egyetlen C++ feature van csak amire ez nem igaz: a kivételkezelés! (bár fene tudja, lehet ha nagyon akarom, longjmp segítségével még az is menne... utána kéne néznem de nem ér annyit az ügy...)

Szóval igen, oda való, de elismerem, ő a „legkevésbé idegesítő” a listából. Érdekes hogy mégis az első helyre rakta a kolléga, szerintem utolsó illene legyen... Tulajdonképpen nem is az a baj vele hogy létezik, esetenként tényleg akár még hasznos is tud lenni, csak az a baj hogy eszméletlenül sokszor visszaélnek vele, mert ugye az OOP az istencsászár, amit mindenre alkalmazni KELL, nem számít mennyi az overload miatta...

Elvesztettem a fonalat. Háromszor is elolvastam a kommentedet de nem bírok rájönni, mire célzol. Szerintem a C++ kifejezetten olyan nyelv ami NEM tanulható gyorsan, legalábbis ha a legalapabb alapjainál többet akar róla tudni az ember.

Nem véletlen az se ugye hogy a programnyelveimet eleinte C++ -ban írtam, de aztán inkább sima C -re váltottam. Nemcsak gyorsabb lett tőle minden de még áttekinthetőbb is.

Lehet, hogy azért, mert nem maga a C++ - a nyelv - az, ami olyan nehezen lenne tanulható, hanem az egyre konvulensebbé váló ökoszisztémája? Pythonnál is inkább az ökoszisztéma az, ami problémás, hiszen a nyelvből van olyan implementáció is, amit egy mikrokontroller is elbír. Nagyon sokszor van, hogy egy adott technológiának a nyakába varrják a ráépülő technológiák gyíkjait is és így válik a mag körül kialakult kultúra kritikája a mag kritikájává, holott az ok-okozat összefüggés nem feltétlenül áll meg a kettő között: pl. a PHP alapból is egy elbaszott nyelv, de a ráépülő iszonyatszar webkettes "framework-ök" elbaszottságáról nem maga a nyelv tehet; azon keretrendszerek írói bármilyen más nyelven is csak szart csináltak volna...de ennek ellenére a PHP kritikák állandó és alapvető eleme, hogy mekkora szarokat írtak benne.

Ez érdekes gondolat és részben igazat adok neked. Mindazonáltal én egyszer merészeltem végigkövetni, miféle (és hány!) konstruktor meg destruktor-hívás történik egy tök egyszerű értékadás során, már nem emlékszem pontosan mi volt a feladat de valami olyasmi hogy a=b+c; szóval valami tényleg hótt egyszerű dolog... épp csak mindegyik elem ami itt betűvel van jelölve, egy-egy objektum...

Mindazonáltal ha struktúrákkal oldottam volna meg a dolgot, tényleg pofonegyszerű és villámgyors lett volna.

Így NEM. Oké, mint felhasználó semmit se vettem észre abból hogy „lassú”. Ugyanakkor azonban elszörnyesztett amikor láttam, hogy ebből a tényleg ELEMI egyszerű izéből lett egy olyan szinte végnélküli függvényhívási kígyó, amikoris legalább egy TUCAT alkalommal lett a stack macerálva, mert ugye a függvényhívás azzal jár hogy visszatérési címet menteget el a rendszer, esetenként paraméterátadás is történik (itt okvetlenül hiszen az objektumok THIS pointerét muszáj átadni), emellett a heap-ban is átmenetileg lefoglal magának területeket hogy ideiglenes objektumokat gyártson, majd azokat felszabadítja, a copy-construktort is meghívja, stb...

És mindezt tök FELESLEGESEN, mert ott van rég a balérték célterülete ahová rögtön is nyugodtan betehetné az eredményt...

Mondom, nem emlékszem már rá pontosan, hány FELESLEGES függvényhívást követett el, de nagyságrendileg úgy körülbelül egy tucatnyit.

Hát EZÉRT lassú a C++ a C nyelvvel összevetve...

Oké, nem mindig. De ha objektumokkal dolgozunk, akkor IGEN. Másrészt, ha NEM objektumokkal dolgozunk benne, akkor meg mi a frász indokolja hogy épp C++ -ban programozzunk és ne sima C -ben, hiszen akkor épp azt az „előnyét” nem használjuk amiért tervezve lett ez a nyelv!

Körülbelül ekkor kezdtem el azon gondolkodni hogy jobb lenne „lefokozni” magamat és a sima C nyelvet használni... Nos, megtettem és nem bántam meg. Elismerem, néha fájt kissé a szívem mert ez-az tényleg elegánsabban mutatott volna a kódban ha maradok a C++ mellett. Mindent összevetve azonban, végülis magasan megérte hogy így döntöttem!

A C++-ban nem csak az objektumok vannak "pluszba'". Ott vannak a kiterjesztett típusai, a memóriamanagement-je... A két nyelv nem ugyanarra való. A C++ egy magas szintű nyelv, mint a Pascal, vagy a Rust, azokkal van értelme összehasonlítani, nem a C-vel. Már csak azért is, mert a C a C++-nak subsetje, azaz nyugodtan programozhatsz 99%-ban C-ben, de ha valami kell C++-ból (pl. stringkezelés), akkor azt is használhatod.

Arról mondjuk pont elolvasnék egyszer valami rendes összefoglalót, hogy pontosan miféle mechanizmust is takar ez a C++-nál és pontosan hogy is működik, mert három C++ developer négyféleképpen magyarázza, Strtostrup Strsoup Bjarne bátyánk meg évszámtól függően és így a kívülállóknak nem igazán tiszta a kép, hogy most akkor mi is van pl. a kivételkezeléssel, a check az cost-free, a catch meg triple-cost, vagy mi?

de valami olyasmi hogy a=b+c; szóval valami tényleg hótt egyszerű dolog...

Miért van olyan tippem, hogy valami példán keresztül akarták bemutatni valami olyat, ami komplexebb dolog, csak nem jött át, hogy az egy absztrakció.

Mondom, nem emlékszem már rá pontosan, hány FELESLEGES függvényhívást követett el

És miből gondolod, hogy azokat a függvényhívásokat minden esetben el is követte a lefordított kód és a fordító nem optimalizálta ki?

Másrészt, ha NEM objektumokkal dolgozunk benne, akkor meg mi a frász indokolja hogy épp C++ -ban programozzunk

Objektum orientáltan C-ben is lehet programozni. Kiváló példa erre a GTK. De emlékeimben még él a Quake II forráskódja is, amit ugyan C-ben írtak, de már a függvények elnevezésén is látszott, hogy a készítők valójában egy OO paradigmát húztak rá sok helyen. Ilyenkor viszont adódik a kérdés, hogy akkor már miért nem olyan nyelven írják, amin ezeket sokkal átláthatóbban lehet kifejezni, aztán a többit a fordító megoldja. (Ok, 96-7 óta sokat fejlődtek a C++ fordítók is). Mert ha teszem azt vektorokkal vagy komplex számokkal akarok számolni, akkor nekem kifejezőbb, hogy a = (b + c) * 3. Mint az, hogy a = multiple_vector3_by_scalar(add_vector3(a, b), 3).

Másrészt meg azt kellene megérteni, hogy másra találták ki a két nyelvet: C-t alapvetően rendszerprogramozásra, C++-t alkalmazásfejlesztésre.

Nézd, lehet elmélkedni azon hogy „reméljük a fordító majd kioptimalizálja”, de tény ami tény: a programnyelvem miután átírtam sima C -re, körülbelül két és félszer gyorsabb lett mint amikor még C++ -ban volt megírva! Ugyanaz a programnyelv. Illetve, ez a 2.5 -szeres gyorsaság, ez azért „körülbelül”, mert akadnak olyan tesztek melyekben tízszer is gyorsabban teljesít... szóval ez hogy 2.5 ez inkább az alső „közelítés”, mintegy a „legrosszabb eset”...

Gyakorlatilag tehát mindenféle téren sokkal, SOKKAl gyorsabb lett, hála a C++ ==> C migrációnak.

+ autotools daganategyuttes

+ glib

remember lads, subscribe to pewdiepie!

Ezzel egy kicsit mellé lőttél. Ezért (részben) összeszedegettem neked néhány szilánkot a zinternetről. ;)

A tgz nem is formátum, csak egy tömörített tar. A GNU tar nem támogatja az ACL-t, de

The tar utility is no longer a part of POSIX or the Single Unix Standard.

Egy kis történelem:

  • 1965 - ACL
  • 1979 - tar
  • 1993 - gzip
  • 1995 - pax ("portable archive exchange" is an archiving utility created by POSIX, defined since 1995. Rather than sort out the incompatible options that have crept up between tar and cpio, along with their implementations across various versions of Unix...)
  • 1999 - sudo - linuxon
  • 1997, 2001 - ACL POSIX std
  • 2002 - ACL - linux

Tehát egyszerűen csak nem a megfelelő programot használod, de elvárnád tőle, hogy mindent is tudjon. ;)

Egy kb. 97-es történetem meg úgy szól, hogy egy programomat portoltam volna AIX->SCO. Persze nem találtam az ACL specifikus parancsokat. Felhívtam az SCO-s fiúkat, de nem volt válasz. Végül egy IBM guru felfedte az igazságot: Az AIX B2 biztonsági besorolású, az SCO meg csak C4, ezért nincs benne ACL. Így aztán jobb híján csináltam talán még egy groupot és írtam egy "ACL emulációt", ami nem volt teljesen transzparens, de több parancs is kellett hozzá.

Szerintem az ACL sok esetben szükséges, nagyon jól használható. Talán csak nem voltál még olyan helyzetben, amikor szükség lett volna rá.

ACL-t is tárol. (Persze AIX-on másképp, mint Linuxon.)

Minden bizonnyal nem az AIX a hibás. ;)

A "spéci" tar és egyebeket sem jól fogod fel. Az AIX (pl) rendelkezik backup utility parancsokkal. Ebben az esetben hardver, az operációs rendszer, az implementált fs (és annak képességei szerint, pl. ACL) képes a parancskészlet a rendszer mentésre. Ezt nem spécinek, hanem konzisztensnek hívják. :-D

Ha linuxon lett volna ACL, akkor semmi szükség sem lenne a sudo-ra.

Nagyra értékelem a szorgalmadat, ezek alapján esetleg átminősíthetjük az ACL-t _melléksodratú idealizmussá:_ nem minden fájlrendszeren van, nem minden Unix-szerű rendszerben van, de semelyik kettőben nincs egyfomán.

Off: egyébként a `tar`-nak is van egy érdekes/furcsa/problémás featúrája: mint tape-archiver, az utolsó fájl mögé még ír pár üres blokkot, hogy hangsúlyozza a fájl végét.

Ha `append` működést kérünk, akkor ezeket az üres blokkokat leszedi a fájl végéről, és úgy folytatja az írást, semmi gond.

Kivéve, ha az archivum még tömörített is. Ugyebár a compress-t kivéve minden tömörítő tud kibontani appenddel összerakott fájlokat (gunzip(gzip(A)+gzip(B))=A+B), tehát ezzel nem lenne baj, viszont a tar fájlvéget jelentő nulla blockjai ott maradnak a közepén.

nem minden fájlrendszeren van, nem minden Unix-szerű rendszerben van, de semelyik kettőben nincs egyfomán.

Mint ahogyan a lakásod bejárati ajtaját is sokkal gagyibb zárral véded, mint a Fort Knox páncéltermét. Sőt, a Trabant szelepei is tök mások, mint egy Ferrariban.

Szóval egy pendrive esetén, netalántánhacsaknem nincs szükség ACL-re. Meg ott sincs szükség ACL-re, ahol nincs szükség ACL-re. :-DDD

Az ACL szerintem néha lehet oprendszer/fs specifikus. De talán két POSIX rendszer között egészen kis munkával átvihető.

Még egy apró példa az alkalmazásra: Egy (régi, tehát mindenki maradjon csendben!) rendszeren (AIX) van egy csomó ftpuser. Minden védelem tökéletesen megoldott, de nem szerettem volna a rendszer jogosultságait módosítgatni. Ugyanúgy feleslegesen bonyodalom lenne a chroot vagy Rsh alkalmazása. Ott a luk, ha teleírod a /tmp-t, akkor megállhat az oprendszer. A rajta levő sticky bit sem segít. Marad az ACL a /tmp-re: minden ftpuser-re specify: ---, hiszen úgy is script végzi az user felvételt és a munkaterület kialakítását, elfér az az egy sor.

egyébként a `tar`-nak is van egy érdekes/furcsa/problémás featúrája

Ez csak nem *nix rendszerekre igaz (pl. windows ubuntu shell nélkül), mert a többi rendszeren implementált a -i opció. A magyarázat egyszerű: Ha sikerult felírni valamit az EOF-ig, akkor örülünk. Ha folytatni kell az írást, akkor hozzá nem nyúlunk ahhoz, ami már egyszer jól ott van!

Példa: Áthozok egy adatbázis dumpot (tgz) a hálózaton és ellenőrzöm. Ez egy éles mentés, tehát csak olvasni szabad, vagy törölni, ha nem kell már. Az adatbázishoz tartozik némi metaadat (tgz), amit nemes egyszerűséggel appendálok: cat >>. Ezt a gzip tulajdonságai miatt megtehetem, mert gz1+gz2 is gz lesz, csak lesz közben még egy gzip header. Viszont beszorult a két fájl közé egy EOF, de azt a -i opcióval pont át lehet lépni.

Továbbképzési javaslat: Szerezz egy 9 track szalagegységet, és gyakorlatozz a tctl paranccsal! Mondjuk rakj össze blokkonként valamilyen formátumot! ;)

nem szerettem volna a rendszer jogosultságait módosítgatni

Házi Feladat: TCB environment, tcbck. ;)

Hasonlóan hibás elgondolás a chown józsika:pistike / is. :-D Az ilyen ötletekkel egy biztonsági auditon repülsz, mint a papírsárkány.

Persze az auditot sem auditált figurák végzik. Kifogásolták, hogy sok-sok user (akik ftp only, hiszen a /etc/ftpusers-ben laknak) régen nem jelentkeztek be. (Know-how: ADMCHG flag)

Naszóval: Az AIX egy nagyon gondosan tervezett rendszer. Minden olyan ötlet rossz, amikor az operációs rendszer elemeinek default tulajdonosát/jogosultságát megváltoztatod. A 64 bites rendszert meg eleve tcb-vel lehet csak felrakni. Bármilyen jogosultságot módosíthtasz, be is rakhatod a tcb-be, aztán jön a meglepi, amikor nem fut valami.

A tar valami ilyesmi, pont ezt csinája a -i.

ad1: Ha nagyon szőrszálhasogatóan nézzük, akkor az ACL is a rendszer jogosultságait változtatja, csak kevésbé szembeötlő módon.

ad2: A tar-nál -i az kibontáskori opció, tehát nem megoldás arra a feladatra, hogy eleve a becsomagoláskor ne kerüljön bele a fájlvéget jelző nulla-block.

Ki hitte volna! ;)

Az alap jogosultságok a rendszer működéséhez kellenek, míg az ACL-t nevezhetjük exceptionnak. A "kevésbé szembeötlő módot" cserélném a "számodra nem megszokott módra". ;) Az ACL nem "egyszer csak arra jár", hanem valamilyen oka van az odakerülésének. A néhány százezer fájlt sem szemrevételezéssel ellenőrzöd, hanem a tcbck-val. 

Értem, mit csinálsz a tarral. Csak azt nem, hogy miért zavar a sok (jól)tömörített  nulla. A konkatenált tömörített daraboknak külön headere van, ami legalább annyi helyet foglal.  Az egyetlen magyarázat az lehet, ha az adatok felhasználása olyan rendszeren történik, ahol nincs -i opció.

Nincs is szebb a "logolas helyett tiltas" hozzaallasnal, aminek az a vege, hogy senki nem tud dolgozni, mert mindenki permissionokre var. (Banknal mondjuk ertheto, hogy miert muszaj, de sok ceg indokolatlanul unpermissive sok eve ott levo es nyilvanvaloan security-aware alkalmazottakkal szemben is).

Igazán nem kötözködni szeretnék, de talán egy gondosan tervezett rendszeren nincs szükség a jogosultságok ad hoc átlépésére vagy a kísérletek naplózására. Bár tényleg jól hangzik. ;)

Persze egy rendszerközeli parancsnál az AIX és linux man page között az a szembeötlő külöbség, hogy az előbbinél van security fejezet is. A többi már csak következmény. :(

Banknal mondjuk ertheto, hogy miert muszaj

Banknál is néha túl lelkesek a kollégák, és néha erővel akarják megoldani azt a problémát, ami nem is létezik. Az, hogy pl. egy scrumos PDF infografika letöltéséhez ticketet kellett nyitnom, amit a csapatunkkal használtunk volna, az nonszensz.

A másik kedvencem a policy violation, amit azért kaptam, mert a saját mobilomról a dolgozói wifi AP-n (nem intranet!) keresztül egy virágküldő cég webshopjára akartam felmenni a párom szülinapja miatt, ami a rendszer szerint Sex/Dating, ezért rohadjak meg.

Aláírtam a titoktartásit, szerződést, stb., ha a valami policy ellenes dolgot töltök le, akkor verjenek rá huszonötöt, de addig kezeljenek felnőttként. :)

" ami a rendszer szerint Sex/Dating " - a besorolást nem a helyi erők végzik, hanem vásárolt/előfizetett szolgáltatással történik az ilyen szűrés - legalábbis jobb helyeken. Mondjuk találtam már oda/vissza hibákat nem egy ilyen motyóban - jeleztem, hogy mi van szeritnem rossz helyen, és a következő frissítésben már jó volt. Mivel ott épp naponta kétszer húzta le az eszköz a szűrőlistát, szerintem egész gyorsan reagáltak a túloldalon.

É sigen, sajnos ha valamilyen szabályzatban rögzített szűrés/tiltás alól felmentést/kivételt szeretne az ember, akkor azt bizony végig kell tolni a változáskezelésen, ha tetszik, ha nem. (Gondolom a scrum-os pdf infografika ebbe a körbe került bele.)

É sigen, sajnos ha valamilyen szabályzatban rögzített szűrés/tiltás alól felmentést/kivételt szeretne az ember, akkor azt bizony végig kell tolni a változáskezelésen, ha tetszik, ha nem. (Gondolom a scrum-os pdf infografika ebbe a körbe került bele.)

Többé-kevésbé: nem volt változáskezelés, hanem pár nappal később valaki felvette a ticketet, letöltötte a PDF-et, kirakta egy network share mappába és elküldte emailben, hogy hol találom.

Ez a munkakörömhöz szorosan kapcsolódó anyag volt. 

a besorolást nem a helyi erők végzik, hanem vásárolt/előfizetett szolgáltatással történik az ilyen szűrés - legalábbis jobb helyeken

Én inkább az algoritmust sejtem a háttérben. :)

Bocs de én ideveszek általában mindent ami a configure + make párosnál többet igényel... sőt, azon gondolkodom, maga a configure is jórészt felesleges! A make elég. Legyen a Makefile elején pár sor amiben a fószer önmaga beállítja a megfelelő útvonalakat meg esetleges egyéb hóbelevancokat aztán hajrá!

Ja és mégvalami... Ööö... Nagyon megvernétek, ha felvenném erre a szégyenlistára a Pythont is?

De valahogy statisztikailag Perlben tobbeknek sikerul olvashatatlan kodot irni. Ne ertsd felre, en is lattam mar olvashato Perl kodot, meg is lepodtem, meg ha nekem kene Perl kodot irnom, az is olvashato lenne. De a write-only szubkultura A Perl kozossegben igenis letezo es mas nyelvek kozossegeben peldatlan merteku jelenseg.

Minedn, azaz __MINDEN__ desktop manager!

A WM-ek többsége is, gyakorlatilag minden WM, a teljesen minimalista WM-ek kivételével. Olyanoknak kegyelmeznék meg mint a DWM, SithWM, Awesome, Ratpoison, I3 meg hasonlók...

Fordítóprogram, ami 'UB-optimalizáció' jelszóval szándékosan hibás kódot generál.

Tudós progamnyelv-tervező/szabványosító, aki szerint a NULL-pointer lehetne például egy `int`. Amelyik pointerré alakítva esetleg nem is a csupa nulla bitet jelenti, hanem valami platformspecikus speciális értéket.

Ez egy érdekes kérdés. A NULL attól az, hogy ne törődj a megvalósításával, ő az, ami nem mutat sehova. Ellenkező esetben simán leírhatnánk a p = NULL; helyett azt, hogy p = 0;. Egyébként láttam olyat, hogy valaki ez utóbbit írta pusztán azért, mert egy header-ben látszott, hogy #define NULL 0. A konkrét megvalósításhoz a programozónak szerintem semmi köze. A NULL egy speciális, sehova sem mutató érték. De lehet akármennyi platformtól függően.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Hát a fene tudja. Volt már olyan esetem hogy egy unionban kellett értékeket tárolnom, numerikusat is, pointert is, és nem lehetett tudni a függvény épp mit kap az adott esetben. Mármint, a függvény mindig az unionra mutató pointert kapta meg, de nem tudhatta épp mi van az unionban. A helyzet olyan volt hogy semmi baj akár numerikus az érték, akár pointer, tudniillik mindegyiknél értelmezett a kivonás művelete ugye... de HA a pointer NULL pointer akkor egészen mást kellett csinálnia. És minő szerencse a numerikus érték soha nem lehetett nulla... Azaz, így könnyedén ellenőrizhettem, az érték egy NULL pointer-e. Ha azonban nem építhettem volna arra, a NULL pointer lényegében egy unsigned long long nulla érték numerikusan, akkor ki kellett volna bővítenem az uniont úgy hogy az egy struktúra, amiben benne van az eredeti unionom, ÉS még benne van egy „flag” ami jelzi hogy a paraméter most épp pointer-e vagy numerikus érték... azaz el lett volna bonyolítva az egész mindenség...

Szerkesztve: 2020. 08. 15., szo - 15:26

[del]

A sudo is ilyen fősodratú idealisztikus hülyeség, a nagy egyenlősdi nevében született, mert minek is ugye egy olyan gyökér a rendszerbe aki első az egyenlők közt és több joga van...

Nekem első dolgom ha valami ubuntu-szerű izét telepítek (már ha nagyon muszáj...) hogy sudozok. EGYSZER. De soha többé... ugyanis akkor állítom be a root jelszót...

Természetesen a sudo nem arról szól, hogy ne legyen root, innentől kezdve hiba van az eszmefuttatásodban. Sőt. Mivel a sudo használatával sokkal finomabban lehet szabályozni az egyes felhasználók jogait, éppen hogy sokkal inkább alkalmas annak megvalósítására, hogy a felhasználók ne legyenek egyenlőek.

Egyebkent hogyhogy nem talalt meg ide hajbazer? Ha mar lopjak a nyelvezetet a fosodratu szelsoseges mernokurak?

Szerkesztve: 2020. 08. 16., v - 13:03

Ha mar valaki idesorolta volna a Pythont: en alapbol a Pythont szeretem

DE

a decorator egy "fosodratu idealizmus" "fosodratu szelsoseges mernokuraktol".

Keves masik nyelv hianyolja a sajat nyelvi keszletebol - nem veletlen.

Jo azon kivul valamire, hogy egy egeszseges script kiddie olvashatosagu kodot leront Javacript olvashatosagunal is rosszabbra? Csak a kod olvasa kozben wtf fejjel eltoltott percek szamat noveli a letezese (bar nem olyan extrem mertekben, mint a fentebb emlitett 2200 oldalban dokumentalt uefi, de az idonk akkor is az elso). Gyakoribb az olvashato Python kod, ahol ranezesre lehet tudni ki kivel van. De nehanyan szamomra erthetetlen modon ragaszkodnak a decoratorokhoz, mikozben sima algoritmikus fuggvenysorrend sokkal olvashatobb, akar valtozonevbol is.

Főleg web frameworköknél találkozok decoratorokkal, ott szerintem nem rontja semennyire az olvashatóságot, sőt! Pl. odaraksz egy view függvény elé egy @cache(ttl=60) ami kompakttan jelzi, hogy 1 perces cache-t kap az adott view. Persze ezt se kell túlzásba vinni; ha már 4-5 decorator kerülne egy függvény elé, akkor máshogy oldanám meg a dolgot.

Ha az endpointhoz tartozik a decorator (cached endpoint, rate limit), az tenyleg segit az olvashatosagon. "Megnezzuk ezeket, mielott elkezdjuk", tiszta sor. De lattam mar olyan helyeken, ahol nagyon nemegyertemuve valt, hogy mi milyen sorrendben fut.

+snap

Psszt, elárulom az IP-címemet: 192.168.0.14

(Majdnem az) összes JavaScript keretrendszer, meg úgy általában a webes alkalmazásfejlesztés ökoszisztémája.

> /s ugye?

A legkevésbé sem. A JS az egyik legnagyobb csapás, ami a szakmát érte. Feltalálója 10 nap alatt hányta össze ad-hoc módon, mindennemű koncepció és szisztéma nélkül, viszont minden hülye ötletet gondolkodás és restrikciók nélkül beleszórva. Az eredménye az inkonzisztencia lett. Maga a nyelv is inkonzisztensen viselkedik, inkonzisztens megkötései vannak, inkonzisztens eredményeket ad, de ráadásul még az implementációi is inkonzisztensek: mindegyik JS VM máshogy szar. Ez a nyelv egy nagy katyvasz. Hogy mennyire fasza egy nyelv ez, azt minden rizsánál ékesebben illusztrálja a gombamód szaporodó transpilerek és keretrendszerek száma, hogy már mindegy, hogy miben fejleszti az ember a frontendet, csak JS-ben ne kelljen; vagy egy másik nyelv, vagy egy keretrendszer által biztosított absztrakció, de valami fedje el a JS-t az ember elől... És erre a nyelvre épült az egész "webkettős" idiokrácia, ahol nem az a fontos, hogy a végeredmény jó legyen, hanem, hogy az ember megfeleljen a szakmai elvárásoknak; így fordulhat elő, hogy egy oldal N féle funkcióját M fajta JS keretrendszer hajtja: hát csoda, hogy undorító az egész?

> néha nehéz eldönteni, hogy ez itt az Arany Alkony nyugdíjasotthon belső fóruma, vagy egy egy viszonylag rugalmas gondolkodást kívánó szakma fóruma.

15 évnyi webfejlesztés és többszáz weboldal van a hátam mögött, jópár olyan is, ami sokmillió júzeres forgalmat bonyolított /day, valamint nem egy webes alapú vállalatirányítási rendszer is; nem begyöpösödött nyugdíjas vagyok, aki minden "újdonság" ellen kézzel lábbal tiltakozik, hanem tapasztalatból beszélek...dehát itt ahogy nézem, az a default, hogy aki bármilyen elbaszott "mai" divatszarra rosszat mer mondani, azt - kortól függetlenül - kérdés és a fórumtárs ismerete nélkül, továbbá az érveinek teljes figyelmen kívül hagyásával bekukázzák a kivénhedt bitbaszók közé, hogy menjen és kúrjon seggbe egy PDP-11-est, (ha még emlékszik egyáltalán, hogy hogyan kell baszni, de ha nem, akkor puskázza ki lyukkártyáról), mert a "haladó informatikai eszméket" és a felszopott "modern" "technológiákat" kritizálni istenkáromlásszámba megy és mátrixnyomtatón kiprintelt FORTRAN forráskódokból emelt máglyán kell érte elégetni az illetőt, lehugyozott hamvait pedig arccal lefele eltemetni egy jellemtelen tömegsírba. (BTW, a dzsuvaszkript közel 30 éves, úgyhogy aki abban a nyelvben látja a szupertrendy-hyperhaladó modernséget, az sürgősen forduljon orvoshoz, mert vagy hallucinál a túl sok kávétól, vagy alszik programozás közben...)
Néha nehéz eldönteni, hogy ez itt egy techno-hitgyüli, vagy egy viszonylag kritikus/szkeptikus gondolkodást kívánó szakma fóruma.

Az eredménye az inkonzisztencia lett. Maga a nyelv is inkonzisztensen viselkedik, inkonzisztens megkötései vannak, inkonzisztens eredményeket ad, de ráadásul még az implementációi is inkonzisztensek: mindegyik JS VM máshogy szar. Ez a nyelv egy nagy katyvasz.

Pedig történhetett volna másképpen is...

Tamarin is a free software virtual machine with just-in-time compilation (JIT) support intended to implement the 4th edition of the ECMAScript (ES4) language standard. Tamarin source code originates from ActionScript Virtual Machine 2 (AVM2) developed by Adobe Systems, as introduced within Adobe Flash Player 9, which implements ActionScript 3 scripting language. ActionScript Virtual Machine 2 was donated as open-source to Mozilla Foundation on November 7, 2006, to develop Tamarin as a high-performance virtual machine, with the support from broad Mozilla community, to be used by Mozilla and Adobe Systems in the next generation of their JavaScript and ActionScript engines with the ultimate aim to unify the scripting languages across web browsers and Adobe Flash platform and ease the development of rich better performing web applications.
 

https://en.m.wikipedia.org/wiki/Tamarin_(software)

Valtozott valami 2016 ota ?
Meg mindig React a meno, vagy van mar valami uj ?

Az emeber azt hinne, ie6  hallala utan egyszeru lett a webb,
de  ugy latszik az emberek szeretik megneheziteni a sajat dolgukat ..

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Az emlitett rakok kozul a React es a Typescript hatarozottan megmaradt. A webpack is. Az Angular szerencsere haldoklik, tobbek kozt azert is, mert tul konnyu vele lassu vegeredmenyt implementalni. A Vue kezd olyan lenni, mint a React - ebbol ujabb jonehanyan elhiszik, hogy megis az volt a jo irany.

A vanilla JS / ECMAScript kurvasok fejlodott viszont onmagaban sokat, es legtobb modern autoupdate-es bongeszoben tamogatott is, igy sok trivialis libre mar nincs szukseg, ergo a "szemet mennyisege", amit "hasznalni kell" legalabb kevesebb. Maga a react is elerte, hogy mar ne kelljen annyi szemetet osszeszednie egy sima build and runhoz. Persze tovabbra is hosszasan kell tanulni a React, Typescript es Webpack hulyesegeit, de legalabb mar tenyleg csak ennyit.

Ami meg szinten nem valtozott: meg mindig az van a koztudatban, hogy jo, ha van valami JS-es libed a githubodon, ha egy nap netan a Google-hoz felveteliznel. Igy emiatt tovabbra is minden heten ketszamjegyu JavaScript mikroframework szuletik, ami szuletese utan 5 evvel nem fog tartalmazni 4 evnel fiatalabb commitot, akkor se, ha egy bugtenger. :(