A jelenlegi helyzet szerint a bcachefs-tools karbantartása lehetetlen a Debian stabil verziójában.
[...]
Természetesen, ha a bcachefs-toolsnak nincsenek használható stabil kiadásai, akkor nincsenek LTS kiadásai sem, így bárkinek, aki hosszú távon kívánja támogatni a bcachefs-toolst, saját magának kell viselnie a támogatási terheket, és ha a függőségeket egy csomagban tartalmazza, akkor azokat is.
[...]
Így tehát az én kalandom a bcachefs-tools-szal véget ér. Azt tanácsolom, hogy ha a közeljövőben fontolóra veszed a bcachefs használatát bármilyen termelési környezetben, először gondold át, mennyire fenntartható hosszú távon, és hogy valóban van-e bárki, aki sikeresen biztosít stabil támogatást hozzá.
Részletek itt.
(A cikk nyomokban Mesterséges Intelligencia által szolgáltatott adatokat tartalmaz, így a tartalmát érdemes duplán ellenőrizni!)
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Írja valaki újra nekik Cobolban... :-D
- A hozzászóláshoz be kell jelentkezni
Amiben még mindig karbantarthatóbb lenne, mint Rust-ban.
- A hozzászóláshoz be kell jelentkezni
Szerintem te nem láttál Cobol-ban írt komolyabb kódot...
- A hozzászóláshoz be kell jelentkezni
A hangsúly a szerinteden van.
- A hozzászóláshoz be kell jelentkezni
Nem, hanem azon, hogy szerinted egy spagetti (mert máshogy nagyon nem ment) Cobol kód jobban karbantartható, mint egy rust forrás...
- A hozzászóláshoz be kell jelentkezni
Gejzírként tör felszínre a legacy-ellenesség. Már hiányzott.
- A hozzászóláshoz be kell jelentkezni
Én sem vagyok fiatal, de a Cobol-nak még én is csókolomot köszönök...
- A hozzászóláshoz be kell jelentkezni
jo de hajbi mindenhez is ert es jo hangosan. 35 evig volt Cobol fejleszto, aztan atnyergelt a C-re, ahol 47 evet toltott el, majd Cloud-dal foglalkozott az lemult 60 evben, de itt is kubernetessel az utolso 40-ben. Szoval neki koszonnek csokolommal a sun entirprise 5000-es masinak. :D (eh de jok is voltak azok)
- A hozzászóláshoz be kell jelentkezni
En dolgoztam mar olyan cegnel, ahol egyszerre volt Cobol es Kubernetes is, nem akkora scifi ez.
- A hozzászóláshoz be kell jelentkezni
de azert ugye nem egy ember csinalta mindet? :)
- A hozzászóláshoz be kell jelentkezni
Jellemzoen nem.
- A hozzászóláshoz be kell jelentkezni
ok, en is dolgoztam olyan helyen ahol voltak AIX-ek meg Linuxok, meg Cobol es Kubernetes, megminden.
Itt nem arrol van szo hogy ez nem lenne lehetseges, hanem hogy hajbinak mindennel kapcsolatban is 100+ ev tapasztalata van, mert olyan hangosan tud rola "hozzaerto" modjara nyilatkozni :D Persze reggel azwert el kell olvasnia a kovetkezo szot a hutorol az Y generacios szlengszotarbol amit majd tud hasznalni, mert ugy erzi ettol nem csak hangos bohoc, hanem meno bohoc is lesz :D
- A hozzászóláshoz be kell jelentkezni
Na és akkor ha kicseréled a Cobolt Rustra és a hajbazert egy random trendbuzi babzsákfejlesztőre, akkor meg is kapod azt a tipikus Rustafári archetípust, amiről, akikről általában az ilyen Rust-os topikok szólnak.
- A hozzászóláshoz be kell jelentkezni
de itt rolad volt szo nyuszifiju :D
- A hozzászóláshoz be kell jelentkezni
Akkor meg csak hazudtál.
- A hozzászóláshoz be kell jelentkezni
bedurciztal kiscica? :D
- A hozzászóláshoz be kell jelentkezni
Én tanultam Cobolt annak idején, szerintem simán karbantartható. Nem nagyon lehet benne olyan trükkös dolgokat csinálni, ami miatt bonyolult lenne, és tulajdonképpen aki tud angolul, el fogja tudni olvasni, hogy mit csinál a kód.
- A hozzászóláshoz be kell jelentkezni
Én is tanultam. Aztán láttam éles kódot is... Nagyon nem ugyanaz a szint a kettő... És anno akitől tanultam, rendszeresen megjegyezte, hogy nem csak az számít, hogy mit csinál szó szerint a kód, hanem az is, hogy azon kívül mi történik még. Rendszertől, környezettől függően voltak trükkös dolgok, olyan side effect-ek, és arra építő konstrukciók, hogy az, aki "csak tanulta", az maximum pislogott erősen...
- A hozzászóláshoz be kell jelentkezni
Ez majdnem barmelyik okoszisztemara igaz.
- A hozzászóláshoz be kell jelentkezni
Maradok a C-n....
IDENTIFICATION DIVISION.
PROGRAM-ID. Payroll.
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT EmployeeFile ASSIGN TO 'employees.dat'
ORGANIZATION IS LINE SEQUENTIAL.
SELECT PayrollFile ASSIGN TO 'payroll.dat'
ORGANIZATION IS LINE SEQUENTIAL.
DATA DIVISION.
FILE SECTION.
FD EmployeeFile.
01 EmployeeRecord.
05 EmployeeID PIC 9(5).
05 EmployeeName PIC X(20).
05 HourlyWage PIC 9(3)V99.
05 HoursWorked PIC 9(2)V99.
FD PayrollFile.
01 PayrollRecord.
05 EmployeeIDOut PIC 9(5).
05 EmployeeNameOut PIC X(20).
05 GrossPay PIC 9(5)V99.
WORKING-STORAGE SECTION.
01 WS-EndOfFile PIC X VALUE 'N'.
01 WS-GrossPay PIC 9(5)V99.
PROCEDURE DIVISION.
Begin.
OPEN INPUT EmployeeFile
OPEN OUTPUT PayrollFile
PERFORM UNTIL WS-EndOfFile = 'Y'
READ EmployeeFile
AT END MOVE 'Y' TO WS-EndOfFile
NOT AT END
COMPUTE WS-GrossPay = HourlyWage * HoursWorked
MOVE EmployeeID TO EmployeeIDOut
MOVE EmployeeName TO EmployeeNameOut
MOVE WS-GrossPay TO GrossPay
WRITE PayrollRecord
END-READ
END-PERFORM
CLOSE EmployeeFile
CLOSE PayrollFile
STOP RUN.
- A hozzászóláshoz be kell jelentkezni
A procedure divisionban hiányzik a sorok végéről a pont. syntax error :D
- A hozzászóláshoz be kell jelentkezni
Az infómókai szagportál HWSW üdvöskéje Dömös Zsuzsa esetleg folytathatná a vérbeli RUST-ra váltott csomag karbantartását. Úgyis cikksorozatban értekezett a C nyelv haláláról, és a fényes RUST jövőről :)
Van több cikk is onnan ahonnan ez jött a témában, de elég volt ezt búkmárkolnom.
- A hozzászóláshoz be kell jelentkezni
Ja, ki hitte volna, hogy a Rust nem lesz világmegváltó? Egy csomóan, akik nem kajálták be a hype-ot.
Ez a bcachefs egyébként már Torvladsnál is kiverte a biztosítékot, igaz ez nem a tools, hanem a kerneldriver, de akkor is.
Bár ebben a Debian is kicsit vétkes, mert azt a szintű konzervativizmust nem lehet ma tartani, amit 10-30 éve lehetett. Ma már gyorsabban változnak, fejlődnek, módosulnak a kódok. Kicsit modernizálódott ebben a Debian, gyorsabban adoptálja az új kódokat, de sok minden ma már olyan sebességgel változik, hogy csak a rolling disztrók bírják.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
- A hozzászóláshoz be kell jelentkezni
Régen nekem sem volt "elég friss" a debian.
Ma már ki bírom várni azt a max. két évet.
- A hozzászóláshoz be kell jelentkezni
Bele is nyomorodnék.... (Arch)
Plasma-t használok, wayland-del most már. Nagyon sokáig ellenálltam a wayland-nek, főleg a desktop-omon (1 hete van csak), a céges notin már vagy 1 éve az van. Nem volt rendes session restore, meg egyéb problémák (screen share, stb.) is voltak. Aztán az elmúlt ~2 hónapban minden megjavult. Hetente 2x upgrade-lek és most minden tökéletes. Érzésre olyan ugrás gui sebességben, mint amikor a Cyrix 100MHz-es gépem cseréltem egy pentium 166mx-re. Nem szivesen várnék erre két évet..... pedig, még anno ~25 éve én is debiant használtam desktopnak is.
- A hozzászóláshoz be kell jelentkezni
Van azért még nagyon sok terület, ahol a stabilitás többet ér a frissességnél.
A Rust pedig jó lenne, csak pont ugyan úgy érteni kell hozzá, mint minden máshoz. Nem csodaszer ami magától megold problémákat, hanem egy eszköz, ami segít, ha jól használják.
- A hozzászóláshoz be kell jelentkezni
A C jó, csak pont ugyanúgy érteni kell hozzá, mint minden máshoz. ;)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Ezen az alapon te is írhatnál cikkeket :)
- Indítsd újra a gépet! - Az egészet? - Nem, a felét...
- A hozzászóláshoz be kell jelentkezni
Hát folytatja ma is: A Google szerint nem olyan nehéz a C/C++ kódok Rustra cserélése :-D
A Lenugznak meg annyi meg egy bambi: "A főállásban Microsoftnál dolgozó Wedson Almeida Filho szerint sok fejlesztő kolléga hallani sem szeretne a Rust használatáról a kernelben, és úgy véli, hogy ez a hozzáállás könnyen a Linux visszaszorulásához vezethet a jövőben más alternatívák javára, mivel „a kernelek jövője a memóriabiztos nyelvekben rejlik".
“Az ellenség keze betette a lábát”
- A hozzászóláshoz be kell jelentkezni
erre valo a snap akkor!
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
- A hozzászóláshoz be kell jelentkezni
Szerintem egy bcachefs-tools pont nem való oda. Illetve Debianban alapból nincs snap, bár utólag hozzáadható.
- A hozzászóláshoz be kell jelentkezni
semmire se valo a snap, hogyha nem humorizalok.
Gyűlölöm.
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
- A hozzászóláshoz be kell jelentkezni
Találkozni se találkozok vele. Egyszer kíváncsiságból megnéztem, hogy milyen parancslistája van. Tök átlátható:
trey@alderaan:~$ snap list
Name Version Rev Tracking Publisher Notes
bare 1.0 5 latest/stable canonical✓ base
canonical-livepatch 10.8.3 282 latest/stable canonical✓ -
chromium 127.0.6533.88 2923 latest/stable canonical✓ -
core 16-2.61.4-20240607 17200 latest/stable canonical✓ core
core18 20240612 2829 latest/stable canonical✓ base
core20 20240416 2318 latest/stable canonical✓ base
core22 20240809 1586 latest/stable canonical✓ base
cups 2.4.10-1 1058 latest/stable openprinting✓ -
firefox 129.0.1-1 4757 latest/stable mozilla✓ -
gnome-3-28-1804 3.28.0-19-g98f9e67.98f9e67 198 latest/stable canonical✓ -
gnome-3-38-2004 0+git.efb213a 143 latest/stable canonical✓ -
gnome-42-2204 0+git.510a601 176 latest/stable canonical✓ -
gtk-common-themes 0.1-81-g442e511 1535 latest/stable canonical✓ -
protobuf 3.14.0 52 latest/stable stub classic
snap-store 41.3-77-g7dc86c8 1113 latest/stable/… canonical✓ -
snapd 2.63 21759 latest/stable canonical✓ snapd
snapd-desktop-integration 0.9 178 latest/stable/… canonical✓ -
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
jaja, valami nyugje volt a snapes firefoxnak, ami nem jelentkezik a .deb-es firefoxnal.
Mar nem emlékszem mi volt az, de napokat csesztem el vele, mire váltottam es jo lett.
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
- A hozzászóláshoz be kell jelentkezni
Én olyanról tudok, hogy "válts a snap-es Firefox-ra, abban ez már javítva van" ...
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Te szereted a hivatalos ajánlásokat követni. Remélem itt se lesz másként:
Install Firefox .deb package for Debian-based distributions (Recommended)
innen:
https://support.mozilla.org/en-US/kb/install-firefox-linux#w_install-fi…
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
- A hozzászóláshoz be kell jelentkezni
Így van, szeretem az ajánlásokat követni, ami Ubuntu esetén a snap. Mégiscsak a csomagolóban kell megbízni a végén, hiszen az csinálja fogyasztható csomaghalmazzá a mindenféle FLOSS projektek termékeit. Erről szól a disztribútorság.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Flatpak csomagoknál gyakran jogosultságok megvonása okozza a problémát, ami a Flatseal appal jól kezelhető. Snap-en nincs ilyen tudtommal. snap connections és snap interface parancsokkal lehet kutakodni.
- A hozzászóláshoz be kell jelentkezni
Köszi, ezt nem ismertem!
- A hozzászóláshoz be kell jelentkezni
Épp a napokban frissítettem Kubuntu 22.04-re. A snap Thunderbird nem nyitja meg a levélben lévő URL-eket. Ezt mondjuk nem értem hogy engedték ki :-) Lecseréltem PPA-s .deb-re.
- A hozzászóláshoz be kell jelentkezni
Ez történik amikor olyan valaki próbál karbantartani egy csomagot, aki nem ért hozzá (lásd még openssl fiaskó ~16 éve, https://research.swtch.com/openssl).
A Rustban nincs dynamic linking (hozzáértőknek: most egyszerűsítek), van helyette viszont Cargo, ami kezeli a Rust csomagok letöltését és fordítását. Tehát minimális értelme van annak, hogy Rust csomagokból Debian csomagokat gyártsunk, és utána más Rust csomagokat azokkal buildeljünk, mert ezeket csak fordítás során fogja használni, a dinamikus könytárak futásidejű előnyeit (csak egyszer kell betölteni a memóriába) nem fogja tudni kihasználni.
Ez a Rust ecosystem egy ismert tulajdonsága, egyébként a Go is hasonló módon működik.
Valójában a Debiannak át kell(ene) alakítania a Rust csomagkezelési stratégiáját, és akkor nem lennének ilyen gondjai.
- A hozzászóláshoz be kell jelentkezni
Ha jól értem annyit kellene csinálniuk hogy kicheckolják a forrást, cargo-val letöltik a függőségeket, összeforgatják, lesz belőle egy darab bináris, azt meg a további szükséges egyéb fájlokat (konfig, whatever) beledobják egy deb-be?
- A hozzászóláshoz be kell jelentkezni
Igen, még annyival megbolondítva, hogy a buildeléshez használt függőségeket valahogy el kéne tárolni értelmesen, hogy később pontosan reprodukálni lehessen ugyanazt a binárist ("reproducible builds"). A naív megoldás erre az, hogy ezeket behúzza a "Debian forrás csomagba", de így meg azok mérete fog jó nagyra nőni, kvázi feleslegesen, ha több szoftver is ugyanazt a libet használná.
És itt jön be az, hogy ha egy szoftver egy adott függőségből több verzióval működik együtt, akkor pontosan melyik verziót használja? Mindenből a legújabbat? Az újabb nem biztos, hogy jobb. Vagy fixálja le egy adott major.minor verzióra és csak patch level frissítés legyen egy Debian kiadáson belül? De mi van, ha egy szoftverből kijön egy patch változtatás, ami már nagyobb verziót igényel az adott függőségből.
Vagy próbáljon-e optimalizálni, és azonos verziókat használni több csomag esetén?
Ezért írtam, hogy ki kell találni erre egy jó Rust csomagkezelési stratégiát - aminek az alapelveit egyébként a többi hasonló ecosystemre is alkalmazni lehetne (pl. Go, Python, Java, ...).
- A hozzászóláshoz be kell jelentkezni
Java esetén is ezt úgy oldották meg hogy van egy alkalmazásod amihez hozzá van csomagolva az összes könyvtár. Ezek együtt alkotnak egy egységet. Az alkalmazás fejlesztőjének a felelőssége hogy a különböző könyvtárak kompatibilitását biztosítsa és amennyiben security probléma adódik, akkor frissítse az alkalmazását illetve a hozzá tartozó könyvtárakat is - úgy és abban az ütemben ahogy ezt kell.
A "bináris" függőségeket pedig verziózva a maven repository-k tárolják, amik szét vannak mirrorozva, ha pedig azt akarod biztosítani hogy a világvége (illetve a global maven repo-k leállása) esetén is bármelyik időpillanatban tudjál buildelni, arra ott a vannak a repository managerek amiket a saját infrastrukturádba be tudsz telepíteni és ezzel biztosíthatod hogy a csomagok mindig rendelkezésre álljanak (Nexus Repository, Artifactory, stb.). Nyilván a java bytekód struktúrája miatt nem kell mindenféle platform/os/cputype-ra fordítani, tehát ezt a nyelv sajátossága miatt megspórolod, nem szükséges - legalábbis a külső függőségek számára - a build környezet.
Szerintem a fő kérdés itt a felelősség. Ahogy elkezdődtek a különböző nem operációs rendszer szintű csomagok beszivárogni a disztribúciókba, előjött a kérdés hogy hol a határvonal, kinek mi a felelőssége.
A magam részéről inkább használom a hivatalos fejlesztőktől származó alkalmazásokat (most pl. Keycloak-kal foglalkozom), mint hogy azzal töltsem az időmet, hogy a disztribúcióban valahogy összerakott csomaggal küzdjek, amely lehet hogy jó lesz, de az is benne van hogy nem teljesen. Ebben szerintem a docker/podman/stb. egy nagyon jó irányt mutat, és én inkább mennék ebbe az irányba (postgresql-t, keycloak-ot, stb. mind így futtatok). Terhelést is levesz a distrokról, úgy is fog minden működni ahogy azt a fejlesztők leírják, lehetőségem is van akár párhuzamosan több különböző verziót használni, nem is szemeteli tele a rendszert.
Én inkább ebbe az irányba mennék.
- A hozzászóláshoz be kell jelentkezni
A docker meg az upstream-tól letöltött, kicsomagolt targizi egészen addig jó, amíg nem kell naprakész szoftverleltár, illetve automatikus frissítési lehetőség.
- A hozzászóláshoz be kell jelentkezni
Kell cégen belüli docker repo, és ezzel meg is van a szoftverleltár. Automatikusan persze mindent lehet megpróbálni updatelni kivétel amikor nem töri el az update a meglévő rendszerfunkciókat. Ezt konkrétan tapasztaltuk jó pár éve amikor egy minor! PostgreSQL update törte az alkalmazásunkat. Szerencsére IRC csatin ismertem pár postgresql fejlesztő srácot, és közösen kidebuggoltuk a problémát, amit a következő minor verzióban javítottak is. Mondjuk úgy, nem volt őszinten a mosolyunk.
- A hozzászóláshoz be kell jelentkezni
A konténerben lévő szoftverkomponensekre ekkor sem lesz érdemi leltár, nem fogod tudni megmondani, hogy van-e valahol lukas/sérülékeny mondjuk log4j használatban - csak ha a konténerbe is beleturkálsz. Mert ugye ott is n+1 csomag van fent... De ha épp oda egy lofszjoska-1.0.1.tgz van kicsomagolva, mert az "jobb", mint a csomagban elérhető 1.0.0, akkor ez a komponens sehol sem fog megjelenni...
"egy minor! PostgreSQL update törte az alkalmazásunkat"
tesztkörnyezetben elhasal, ezzel semmi gond: javítani kell, akár az alkalmazás felől, akár a használt külső függőség (jelen esetben PG) felől, és meg van oldva.
- A hozzászóláshoz be kell jelentkezni
akárhogy csurjuk-csavarjuk az összes hozzászólásod oda fut ki, hogy a user a hülye, és elkerülhette volna, hogyha a papirt betartja.
(company protocol, iso tanúsítvány, banki végfelhasználói szerződés, bármi. "Mindösszesen" el kellett volna olvasnia a baj előtt).
Szánalom. Minden irányból.
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
- A hozzászóláshoz be kell jelentkezni
Alapvetően az a cél egy nagy cégnél hogy a folyamatok legyenek annyira kifrankózva, hogy a követelményeket lefedjék és ne hagyják a különböző területeket "feleslegesen kreatívkodni".
- A hozzászóláshoz be kell jelentkezni
Mire gondolsz? Arra, hogy a használt szoftverekről naprakész nyilvántartás kell, illetve a sérülékenységeik tekintetében is naprakész információkkal kell rendelkezni, és a sérülékenység besorolásától függő időnbelül a javítást telepíteni kell? Vagy arra, hogy a minor patch által eltört alkalmazás nem kellene, hogy gondot jelentsen, mivel a patch normális esetben először tesztkörnyezetben kerül telepítésre? Nekem speciel Ubuntu kernelfrissítéssel volt ext4-en problémám - adott workload esetén jelentős teljesítményvesztést tapasztaltunk - a workload teszten nem volt reprodukálható, így élesben okozott minimális impact-ot - a visszaállás is belefért a tervezett leállás időablakába. De egy alkalmazás működése, a DB-oldal változása kapcsán végigtesztelhető szerintem... Egyébként szintén PG, bár még 10-es széria és egy szekérderékra való alkalmazás: egyiknek sem volt baja azzal, hogy 10.x -ből mi volt alatta...
- A hozzászóláshoz be kell jelentkezni
Igazából ebből nekem az a tanulság, hogy rendszerfrissítés előtt bizony végig kell tesztelni az összes alkalmazást ami az adott rendszeren/os-en fut, hogy nem-e tör el valamit véletlenül.
- A hozzászóláshoz be kell jelentkezni
Ha a security az igény akkor a docker scout vagy a snyk megoldja: végignyalja a docker containereket és szépen kilistázza hogy olyan security issue-k lehetnek. Biztos van ezer másik tool ami ezt adja, én ezeket nézegettem.
- A hozzászóláshoz be kell jelentkezni
Ezt meg fogom nézni, köszi.
- A hozzászóláshoz be kell jelentkezni
A konténerben lévő szoftverkomponensekre ekkor sem lesz érdemi leltár
Hat mar hogyne lenne, pont az a lenyege, hogy full reprodukalhato az egesz
- A hozzászóláshoz be kell jelentkezni
És vajon mi fogja begyűjteni a konténerbe belelapátolt csomagok listáját? Mert nem az a releváns infó, hogy rücskösfütykös.2.3.4 konténer, hanem az, hogy a konténerben akarmi.1.0.0_lukas vagy az akarmi.2.3.4_nincs_ismert_serulekenysege van-e?
Oké, ha házi build, akkor lehet csomaglistát feltolni a megfelelő sérülékenységmanagement/nyilvántartó motyóba, ami visít, ha valahol van sérülékeny komponens - viszont erre olyan nyilvántartó cucc kell, ami nem csak a hoston lévő agent-tel gyűjt naprakész infót, hanem képes fogadni telepítési infókat valamilyen értelmes felületen/api-n.
- A hozzászóláshoz be kell jelentkezni
Masok mer emlitettek Snyk eszkozoket, tudsz vele image-t scannelni. A CI/CD pileline a build kozben automatikusan megcsinalja a reportot, hogy milyen sebezhetosegek vannak az image-ben, mind OS mind application oldalon. Az is lehet hogy eltori a build-et ha kritikus sebezhetoseg van.
- A hozzászóláshoz be kell jelentkezni
Igen, erről már volt szó, jó kérdés, hogy az erre szolgáló rendszerbe hogyan kerül bele a lista...
- A hozzászóláshoz be kell jelentkezni
Ne vicceljünk már, hát több csillió security audit meg compliance eszköz van arra, hogy a konténereket kezelje.
Tény, hogy az OS szokásos eszközei erre nem jók, az is tény, hogy vannak benne olyan dolgok, amik így kicsit nehezebbek, és nem trivi ezt csinálni... van itt pár évvel ezelőttről nekem is valahol erről threadem ha jól rémlik, hogy azért a konténer friss az egy csomó kérdést felvet, ahol a kedves programozó úr nem nagyon értette... de azóta lett ebből gyak egy saját terület, ne csináljunk már úgy, mintha nem lenne.
- A hozzászóláshoz be kell jelentkezni
Ez igaz. Csak ahol van elsősorban Windows-vonalra (bár Linuxokra is van, de ott az egyik sír, hogy sérülékeny a kernel, a másik meg a frissítés után sír, hogy nem kompatibilis vele a kernel...) kitalált motyó, saját adatbázissal, saját agent-tel, ott ezekkel kéne integrálni - vagy külön hasonló tudású megoldást összerakni, mert van olyan terület, ami ezt igényli sajnos... A fentebb említett eszközöket megnézem, mert látszik, hogy "mindent is" folyamatosan szemmel kell tartani frissesség és ismert sérülékenységek témakörében.
- A hozzászóláshoz be kell jelentkezni
Ez igaz. Csak ahol van elsősorban Windows-vonalra kitalált motyó, saját adatbázissal, saját agent-tel, ott ezekkel kéne integrálni - vagy külön hasonló tudású megoldást összerakni, mert van olyan terület, ami ezt igényli sajnos...
Ja értem, szóval ugyan van egy komplett terület, ami a konténer securityvel foglalkozik, de jött az észosztás, hogy "És vajon mi fogja begyűjteni a konténerbe belelapátolt csomagok listáját? Mert nem az a releváns infó, hogy rücskösfütykös.2.3.4 konténer, hanem az, hogy a konténerben akarmi.1.0.0_lukas vagy az akarmi.2.3.4_nincs_ismert_serulekenysege van-e?" mert valójában fingod nem volt róla, hogy ezek léteznek, mert a windowsra való eszközöd ezekre nem való. Aztán ha felhívja az ember a figyelmed rá, hogy de hát ezekre a kérdésekre van válasz, nyilván nem a konténer verzióját nézi semmi, akkor meg akkor az a baj, hogy hát miért nem integrálódik a meglévő izédbe (hint, mivel ezek jellemzően viszonylag friss megoldások, szinte mindig van apijuk, szóval hajrá).
(bár Linuxokra is van, de ott az egyik sír, hogy sérülékeny a kernel, a másik meg a frissítés után sír, hogy nem kompatibilis vele a kernel...)
Ja, hát bizony van az úgy a securityban, hogy nem elég pipálgatni, hogy kész van, mert zöld, gondolkozni is kell, mikor szembe jön a valóság :)
- A hozzászóláshoz be kell jelentkezni
Nincs komplett terület, ami azzal foglalkozna, hogy milyen szemetet hoz magával az x, y meg z konténer. A meglévő megoldások jellemzően az OS_ben futó agent-tel szedik össze az infókat, és adnak átfogó leltárt a használt szoftverekről, verziókról, azoknak az ismert sérülékenységeiről. Windows, Linux, működik. Konténerbe ezek nem néznek, nem látnak bele, így mindenképp kell egy külön eszköz arra, hogy a konténerek belsejében lévő komponensek ilyen adatait begyűjtse, és jó esetben ebbe a rendszerbe valamilyen módon integrálhat legyen.
Erre kaptam ötleteket, azokat nézem, hogy hogyan lehetne megvalósítani a host - szoftverlista "mintájára" a "konténer - szoftverlista" relációknak a kezelését az adott sw-leltár/sw audit motyóval.
- A hozzászóláshoz be kell jelentkezni
Nincs komplett terület, ami azzal foglalkozna, hogy milyen szemetet hoz magával az x, y meg z konténer.
Már hogyne lenne. Annyira nincs, hogy pl nincs róla gartner study már hat évvel ezelőttről is azzal a címében hogy "maturing". Nem akar lépten nyomon minden CI/CD, kontainer management, orchestraiton meg hasonló platfrom container securityit eladni neked :D
A meglévő megoldások
Mármint hogy a nálatok meglevő, meg az általad ismert megoldások.
Erre kaptam ötleteket, azokat nézem, hogy hogyan lehetne megvalósítani a host - szoftverlista "mintájára" a "konténer - szoftverlista" relációknak a kezelését az adott sw-leltár/sw audit motyóval.
Mármint kaptál egy szoftvert, és most örülsz, holott onnan indultál kárörvendve magas lóról, hogy hát ilyen nincs. Dehogy nincs, gyak egy egész iparág lett rá az elmúlt években, csak le tetszett maradni :)
- A hozzászóláshoz be kell jelentkezni
És vajon mi fogja begyűjteni a konténerbe belelapátolt csomagok listáját?
En mar a kerdest sem ertem, pedig jo sokat foglalkoztam kontenerekkel. Ki lapatol bele, micsodat, es hova?
- A hozzászóláshoz be kell jelentkezni
Az apt install (nyilván értsd generikusan) a Dockerfileban (nyilván értsd generikusan)?
- A hozzászóláshoz be kell jelentkezni
Nem tudom, nem koltoi kerdesnek szantam. Ami a Dockerfile-ban van*, az nekem pont, hogy nem "lapatolas", hanem egy egesz jol** meghatarozhato, leirhato es reprodukalhato folyamat.
* Ertsd jol, ha a Dockerfile leklonozza egy Git repobol a mindenkori mastert, lebuildeli, felrakja automatikusan a fuggosegeit, akkor nyilvan nem.
** Nyilvan van vegtelen modszer ezen belul, hogy minel egzaktabb dolgok tortenjenek, de alapvetoen egy apt install relativ keves side effecttel rendelkezik, plane ha van version pinning is hozza. Siman meg tudod nezni, hogy miket hoz magaval. De ha ez sem eleg, akkor tetszolegesen lehet tovabb "szigoritani" a receptet.
- A hozzászóláshoz be kell jelentkezni
Persze, lehet ezt jól csinálni, de ahhoz bizony itt is gondolkozni, és érteni kell, mi történik, és természetesen elő is lehet állítani ezt a listát (akkor is, ha kézzel bemászós docker commitos volt a készítés módszere egyébként), de ettől még ez a lista releváns.
A lapátolást szemantikáján én nem akadtam fent, simán csak installnak vettem, de értem :)
- A hozzászóláshoz be kell jelentkezni
Sajnos lapátolás is adódik, mert van, amit ilyenkor is az upstream-ból tgz-ben lehúzva "lapátolnak" bele a konténerbe, ahogy azt tették natívan, konténer nélkül.
- A hozzászóláshoz be kell jelentkezni
Aha. Szóval van egy vendor, aki eddig is fosul csinálta, és most is úgy csinálja :)
- A hozzászóláshoz be kell jelentkezni
Sajnos amíg nincs az adott motyóból rendszeresen frissített (sőt gyakorlatilag semmilyen) repóból telepíthető csomag, addig ezt fogja csinálni... :-/
- A hozzászóláshoz be kell jelentkezni
De hat a mienkbol sincs repo-s csomag, megis egeszen pontosan meg tudom mondani, hogy az image-eknel melyik tag milyen verziot szallit, es annak pontosan mik a fuggosegei. Ehhez nem kell repobol telepitheto csomag.
- A hozzászóláshoz be kell jelentkezni
Őőőő, hát azért a realitások talaján maradva, mondjuk inkább, hogy lehet akár full reprodukálható is :)
- A hozzászóláshoz be kell jelentkezni
Eeegen, most hagyjuk figyelmen kivul az olyanokat, amikor az illetekes kontenermernok ur behuzza a ubi9/ubi-init image-et komplett systemd-vel, belep a kontenerbe, feltelepit mindent kezzel, majd `docker commit, es kesz a kontener.
Persze igy belegondolva ez megmagyarazza zeller kerdeset, ha ok is igy dolgoznak.
- A hozzászóláshoz be kell jelentkezni
Ahh, másik szál, bocs, törölve.
- A hozzászóláshoz be kell jelentkezni
Szóval azért nem annyira trivi ez. Én még emlékszem pl arra, mikor a dockeresek azt magyarázták, hogy mindenki hülye, aki változót akar behelyettesíteni egy dockerfileba a from-ba, mert akkor nem lesz repprodukálható, hát nem értitek ezt az egészet... a mindenki hülye meg azt próbálta megmagyarázni, hogy de bazmeg én a CIból a konkrétumot írnám be oda, és attól még hogy beírom, hogy "énkicsipónim:latest" attól még nem lesz reprodukálható :)
És hát, amíg a konténerek jelentős része úgy keletkezik, hogy "apt install foo bar baz", addig ugye a full reprodukálhatóhoz kell az, hogy legyen egy snapshot arról az apt repóról, annak híján nehéz lesz garantáltan ugyanazt előállítani. Ami persze nem feltétlen baj, de gondolkozni kell hozzá, hogy mi a good enough reprodukció az adott esetben. És azér én úgy látom, hogy ez sokszor nincs meg, egyszeri programozó gyakran a problémát sem igazán érti.
- A hozzászóláshoz be kell jelentkezni
Vilagos, persze, ezekkel egyetertek. Szerintem kicsit alacsony lett itt is a belepesi kuszob, gyakorlatilag 5 perc tutorial olvasgatas kell ahhoz, hogy csinalj egy kontenert valamibol, aztan utana meg 1-2 ev, mire a buktatokra is rajossz :)
- A hozzászóláshoz be kell jelentkezni
Jep. :)
- A hozzászóláshoz be kell jelentkezni
Nem így történik, automatizált a build, tehát reprodukálható - lenne, de mivel ami repóból érkezik, az frissülhet közben (de ez legalább "látszik" csomaglistában), viszont ami upstream-ből targézében, az maximum a build során derül ki, hogy épp milyen verzió, bár ez ellen egyszerűen a saját repóba lehúzott, és onnan a konténerbe rakott komponenssel lehet tenni, pont a reprodukálhatóság érdekében.
Aki egy futó konténerben perzisztensnek szánt módosítás követ el, az más galádságra is képes, ez tiszta sor :-)
- A hozzászóláshoz be kell jelentkezni
Ért ő hozzá, csak Rust-hoz nem ért. Olyasmi ez, mintha magyar ügyvéd lennél majd hoznának egy törvényt arról, hogy Magyarország államnyelve holnaptól a svéd lesz. Közlönyök, törvények, szerződések, tárgyalások onnantól svéd nyelven lesznek. Meg lennél lőve, ahogy minden olyan magyar ügyvéd is, aki nem beszél svédül.
- A hozzászóláshoz be kell jelentkezni
direkt azért néztem be ide, hogy találok-e valami értelmes magyarázatot, thx
- A hozzászóláshoz be kell jelentkezni
Kicsit hasonló, én azon ütköztem meg, hogy debian 12-re akartam ntpdate-et telepíteni. Régen ez kb. egy ~100k-s csomag volt (embedded rendszerről beszélünk).
És akkor jött a hidegzuhany: python3 dependency meg a világmindenség.
- A hozzászóláshoz be kell jelentkezni
A python3-at ma már annyi minden használja, hogy nem tudom elképzelni hogy ne volna fenn mindenhol mint az alaprendszer része. Felteszem, hogy az ntpdate fejlesztője is erre gondolhatott. (Csak hát az embedded rendszer nem volt belekalkulálva...)
- A hozzászóláshoz be kell jelentkezni
debian... emlexem anno ha fel akartad rakni (szreverre) az mc-t, felrakta az X-et meg meg vagy 200 csomagot fuggosegnek.
az exim-et meg nem lehetett lecserelni, mert leszedni se engedte (mandatory) de amig fennvan addig mas mta-t se lehetett felrakni.
- A hozzászóláshoz be kell jelentkezni
Az k*rva régen volt, de jah
- A hozzászóláshoz be kell jelentkezni
Nem értek hozzá, ezért kérdezek.
Kb 22-24 éve figyelem a fejlesztők igényeit kiszolgáló fejlesztéseket. Vagyis lett egy divatos nyelv nosza mindenki használja azt, aki nem használja az minimum őskövület vagy *zi.
Emlékszem amikor még perl volt a tuti aztán lett a python, de ezelőtt a pascal-t kellet kisöpörni (ezt megértem valamelyest).
Amit ebben a trendben látok nem más mint a helyben topogás egy fajtája. Néha csak újra írják a megkívánt kódot és nincs fejlődés, sőt egy rakás hiba kerül a kódba. A hibák érthetőek, hiszen nem lehet elsőre tökéletest alkotni, de ezek nincsenek a régi kódban.
Megéri ez a kódolói / programozói "vagánykodás"? A sok párhuzamosan beleölt energiával. Nem lenne célszerűbb csak a friss ötleteket az új és jobbnak gondolt nyelven írni?
- A hozzászóláshoz be kell jelentkezni
Valahogy így. Ha már van egy meglévő kódbázis, azt már sok szem látta, a nagy számok törvénye szerint sok hibát javítottak benne az idők során. Erre jön egy új nyelv, újraírják nem kevés erőforrás elpazarolásával, aztán igazából rosszabb lesz, mint volt. Kezdődhet előlről a hibakeresés!
De hát ez memória biztos, stb...
Az... És láss csodát, egy év múlva már nem tudod lefordítani, vagy csak óriási plussz munkával, amit lehetne esetleg a meglévő kódbázis hibáinak keresésére is használni pl.
- A hozzászóláshoz be kell jelentkezni
A perl az sosem volt jó, az egy rossz, write only nyelv volt, csak akkoriban nem volt más. A PHP cserélte egyébként, ami ugyanúgy egy tákolmány volt anno, de mostanra sikerült elég szépen kikupálni. A python is megtalálta a helyét, de nem ott, ahol bárki is gondolta volna (data analytics, data science, machine learning).
Igazából az összes ilyen projektnél az a probléma hogy pár lelkes ember fejleszti, aztán amikor elege van a meglévő kódbázis tákolásából, akkor inkább azonos néven újraírja. Itt egy hibát követtek el: hagyni kellett volna a C kódot ahogy van és az egészet, új néven, 0-ról újraírni RUST-ban, aztán tartsa karba a régi kódbázist az aki akarja - vagy akinek fizetnek. Az eredmény egyébként kb. pontosan ugyanez lett volna mint a jelenlegi helyzet.
Céges környezetben egyébként is hasonló történik: olyan szinten karbantarthatatlanná válik a kódbázis, hogy egyszerűbb kukázni és újrairni az új igényeknek megfelelően.
- A hozzászóláshoz be kell jelentkezni
"A perl az sosem volt jó, az egy rossz, write only nyelv volt"
Lóf@sztmama, hogy finoman fogalmazzak... Majdnem bármilyen nyelven lehet gányolt, kezelhetetlen, writeonly kódot fosni, és Perl-ben is lehet jót és hónapok múlva, mások számára is érthető, követhető programot elkövetni.
Annyi, hogy nem hátulgombolósok kezébe való :-P (Egyébként a péhápé is egy gány tákolmány amúgy, messze nem kupálódott ki annyira tisztára, mint a Perl...)
- A hozzászóláshoz be kell jelentkezni
Kb 22-24 éve figyelem a fejlesztők igényeit kiszolgáló fejlesztéseket. Vagyis lett egy divatos nyelv nosza mindenki használja azt, aki nem használja az minimum őskövület vagy *zi.
És közben van egy kemény mag (Linus és co., Theo & co. stb.), aki ez idő alatt maradt a C-nél és nem érti, hogy mi történt itt.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Ez egy teljesen logikus döntés. Van egy elég nagy kódbázis amit karban kell tartani, nyugdíjig, sőt még azután is ellesznek vele, igazából ennyi.
- A hozzászóláshoz be kell jelentkezni
En nem erzem helyben topogasnak. En ugy latom bizonyos feladatokra szituaciokra alakulnak ki nyelvek, amik vagy sikeresek lesznek mas teruleten is vagy nem.
- A hardware kozeli embedded, low resource kornyezetben van a C, assembly, mert nincs mas ami ugyanazt tudna, ehhez jon most a rust. Egyik sem egyszeru, nehez megtanulni, meg nehezebb profinak lenni benne.
- Automatizalas, kissebb hobby projectek, startup cegek, ahol a gyors eredmeny a fontos ott a python verhetetlen. Konnyu megtanulni, konnyu benne gyors eredmenyt elerni, de szerintem igazan profinak lenni benne nagyon nehez. Es egy bizonyos meret felett nagyon nehezkes es sebesseg teren nem az optimalisabb.
- Univerzalis nyelvek, univerzalis feladatokra: Java, C++, C# ..... Nem konnyu megtanulni, de nagy projecteket lehet benne, hatekonyan fejleszteni.
- Javascript: hat ez egy kakukktojas, reszteruletre lett kitalava de mar mindenre is hasznaljak. Azt hiszed konyu megtanulni, pedig nem, azt hiszed erted, pedig nem, egy eleten at lehet vele penzt keresni, de nem biztos hogy akarod is.
Persze az osszefoglalas leegyszerusito es sok mindent nem taralmaz, de a lenyeg hogy az uj nyelvek azert szuletnek mert igeny van ra. Egy problemat pl security alacsony szinten akarnak megoldani igy szuletett a rust. Vagy egyszeru konkurrens programozas igy szuletett a GO.
- A hozzászóláshoz be kell jelentkezni
Javascript: ennél undorítóbb dolgot nem láttam még.
A C-nek megvannak ugyan a nehézségei, de ha az ember fegyelmezett és érti, hogy mit csinál, ami nem azonos azzal, hogy a neten valamiféle példákat, template-eket copy-paste-elünk - nem is értem, hogyan tudnak egyesek így „programozni”, mert vannak -, akkor nagyon tiszta, logikus nyelv, gyors lesz a kód, amivé fordul és még működni is fog. Jól. Igen jól.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
> Javascript: ennél undorítóbb dolgot nem láttam még.
annyira nem rossz azert, csak a helyen kell tudni kezelni, es arra hasznalni amire valo: weben baromkodni :)
> hogyan tudnak egyesek így „programozni”, mert vannak -
ez minden nyelvre igaz amugy
- A hozzászóláshoz be kell jelentkezni
ez minden nyelvre igaz amugy
Úgy vettem észre, hogy az itteni körökben csak a Cre igaz, hogy azzal semmi baj nincs, csak tudni kell használni, bármi másra az igaz, hogy a hülyéktől úgy se véd meg, ott nem alapvetés, hogy a programozó tudja használni (lásd ugye ~bármelyik rustos thread).
- A hozzászóláshoz be kell jelentkezni
akkor nagyon tiszta, logikus nyelv
Hát, ezt inkább csak a stockholm szindrómád mondatja veled szerintem. Én ugyan nem vagyok C programozó (bár tanultam, néha bele is túrok, és rendszeresen olvasok c kódot), de csak ha itt belegondolok, hogy hány olyan topic volt -- jó részükben részvételeddel -- ahol a c programozók azon beszélgettek hosszan, hogy itt vajon mi is történik, és hányszor lett a "megoldás" az, hogy hát a leírt kód valójában undefined behavior, abból nem az jön ki, hogy ez egy tiszta, logikus nyelv lenne.
A javascript szerintem is ronda, de ez a rakás egymásba ágyazva definiált anonim függvény valójában ízlés kérdése*, van is benne agyfasz is jó pár, de igazából messze nem annyi így érzésre, mint amit csak itt felrángattatok a C-ről :)
még működni is fog. Jól. Igen jól.
Hát, pl a CVE adatbázis továbbra sem erről tanúskodik :)
* még azt is megkockáztatom, hogy abban a környezetben egy idő után megszokod, és nem kell sok felesleges sallangot kiírnod, mert ott az egész execution egyébként is callbackekre épül. Én írtam kódot python twistedben (az egy async io framework gyakorlatilag, hasonló execution modellel mint a js) a sima callbackekkel az asnyc defek előtti stílusban, sima kézzel csinált deferredekkel, meg ráaggadott callback listákkal, hát nem vagyok benne biztos, hogy nem lett volna olvashatóbb helyben definiált anonim függvényekkel írni.
- A hozzászóláshoz be kell jelentkezni
Persze, C-ben van egy rakás öröklött dolog, ami kompatibilitás miatt megmaradt. Hovatovább nem írok int típust, mert nem tudom, mekkora, mikor fog túlcsordulni, vagy mondjuk lekérdezem, hogy ezen a konkrét processzoron mekkora, majd egy másikon meg nem. Jó lesz nekem az int8_t, int16_t, int32_t, esetleg int64_t, 8 bites architektúrán akár int24_t is lehet. Ezzel csak azt akarom mondani, ha valami bizonytalanságot érez az ember, az mindig megkerülhető, megkonstruálható úgy a kifejezés vagy adatstruktúra, hogy az működőképes, világos legyen. Nyilván veszélyes az, ha valaki byte-os tömbre 16 vagy 32 bites pointer kasztolással hivatkozik, s elfelejtette align-olni a tömböt, mert a fordító simán lefordatja páratlan címre vagy nem néggyel osztható címre a hivatkozást, a CPU-ban pedig egy vaskos exception keletkezik futásidőben. Ránézésre, ha nem gondolunk utána a hardware szempontjai szerint, akkor minden jó.
Személyeskedés nélkül némileg elegánsabb lett volna a hozzászólásod. Nem értem, mi szükség van erre, de ha ettől érzed jobban magad, nem fosztalak meg az élménytől.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Persze, C-ben van egy rakás öröklött dolog, ami kompatibilitás miatt megmaradt. Hovatovább nem írok int típust, mert nem tudom, mekkora, mikor fog túlcsordulni, vagy mondjuk lekérdezem, hogy ezen a konkrét processzoron mekkora, majd egy másikon meg nem. Jó lesz nekem az int8_t, int16_t, int32_t, esetleg int64_t, 8 bites architektúrán akár int24_t is lehet. Ezzel csak azt akarom mondani, ha valami bizonytalanságot érez az ember, az mindig megkerülhető, megkonstruálható úgy a kifejezés vagy adatstruktúra, hogy az működőképes, világos legyen. Nyilván veszélyes az, ha valaki byte-os tömbre 16 vagy 32 bites pointer kasztolással hivatkozik, s elfelejtette align-olni a tömböt, mert a fordító simán lefordatja páratlan címre vagy nem néggyel osztható címre a hivatkozást, a CPU-ban pedig egy vaskos exception keletkezik futásidőben. Ránézésre, ha nem gondolunk utána a hardware szempontjai szerint, akkor minden jó.
És ezek azok, amik miatt valójában ez nem egy tiszta, logikus nyelv, ha bizonytalanságokat kell kerülgetni :)
Személyeskedés nélkül némileg elegánsabb lett volna a hozzászólásod. Nem értem, mi szükség van erre, de ha ettől érzed jobban magad, nem fosztalak meg az élménytől.
Nem igazán látom személyeskedésnek hogy
a) hivatkoztam arra, hogy ezekben te is részt veszel, és neked sem tiszták és világosak sokszor, pedig C programozó vagy
b) meg arra, hogy azért tűnhet logikusabbanak, mert már beleszoktál a hülyeségeibe?
- A hozzászóláshoz be kell jelentkezni
És ezek azok, amik miatt valójában ez nem egy tiszta, logikus nyelv, ha bizonytalanságokat kell kerülgetni :)
Ja, aki hülye a hardware-hez, az ne programozzon! Assembly-ben mit csinálna a nyomorult? Mert arra aztán nem mondhatod, hogy logikátlan, ugyanis az a pőre valóság, a CPU utasításai és a hardware regiszterei.
Nem igazán látom személyeskedésnek
Rögtön az elején diagnosztizáltál, mert mindenki szakavatott orvos, jogász, futball szakértő, mérnök ebben az országban, nem is értem, mi szükség van nálunk szakember-képzésre. Ha még Sanya írta volna, bár akkor sem lenne túl szép.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Ja, aki hülye a hardware-hez, az ne programozzon! Assembly-ben mit csinálna a nyomorult? Mert arra aztán nem mondhatod, hogy logikátlan, ugyanis az a pőre valóság, a CPU utasításai és a hardware regiszterei.
Jajj ne már. Arról van szó, hogy mennyire átlátható, és tiszta egy nyelv :)
Egyébként ha személyeskedni akarnék, akkor már többször bizonyítottad, hogy a hardverhez lehet hogy értesz, de a programozáshoz, hát ahhoz pont kevésbé, van egy kis része, amit csinálsz, aztán azt hiszed minden szoftverfejlesztés olyan, és rendszeresen osztod az észt úgy, hogy közben le vagy maradva legalább 20 évvel. És azt se vagy képes felfogni, hogy a programozás jelentős része rohadtul nem hardware buzerálásról szól.
Rögtön az elején diagnosztizáltál
A "stockholm szindrómád van" szimplán azt jelenti ebben a környezetben, hogy mivel rohadt régen csinálsz valamit, ezért már nem feltétlen veszed észre, hogy valójában nem minden olyan jó/egyértelmű, csak már megtanultad, hogy ez itt így van. Ez egy szleng/viccess egyszerűsítő kifejezés, de sértődj meg rajta nyugodtan, nem fosztalak meg ettől az élménytől :)
- A hozzászóláshoz be kell jelentkezni
Azt értem, hogy a programozás másról is szól, de engedd meg nekem, hogy ne tartsam sokra azokat, akik legalább minimális hardware ismeretek nélkül programoznak. Igen, van bennem egy hardware-közeli fetisizmus. A nyelv pedig nem attól lesz egy áttekinthetetlen vacak, hogy kell hozzá érteni a hardware-t. Ha semmi hardware ismeret nem kellene akkor nagyjából a volatile kulcsszó huss, értelmetlenné is válna, meg az align-olások, meg a packed struktúrák. De ilyenek bizony vannak, és nem csak úgy az egyszeri programozóval való kiszúrás érdekében, hanem okkal. Ettől a nyelv még nem lesz sem rossz, sem áttekinthetetlen.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Azt értem, hogy a programozás másról is szól, de engedd meg nekem, hogy ne tartsam sokra azokat, akik legalább minimális hardware ismeretek nélkül programoznak.
Megengedem neked. Nekem meg azt engedd meg, hogy ne tartsam sokra azt, aki azt hiszi magáról, hogy programozó, aztán fingja nincs a programozás szakma jelentékeny részéről, és azt rendszeresen elő is adja, hogy az sok fölösleges marhaság, mert ahhoz, amit ő csinál, ez nem kell. Bezzeg ha más valaki mondja, hogy a hw közeli baszogás nélkül remekül el lehet lenni azzal, amit ő csinál, az meg semmire se való, mert miért nem tudja :) Neked miért nincs megközelítő fogalmad se, nem hogy kézzel fogható tapasztalatod bármilyen értelmes tesztelésről?
A nyelv pedig nem attól lesz egy áttekinthetetlen vacak, hogy kell hozzá érteni a hardware-t. Ha semmi hardware ismeret nem kellene akkor nagyjából a volatile kulcsszó huss, értelmetlenné is válna, meg az align-olások, meg a packed struktúrák. De ilyenek bizony vannak, és nem csak úgy az egyszeri programozóval való kiszúrás érdekében, hanem okkal. Ettől a nyelv még nem lesz sem rossz, sem áttekinthetetlen.
Egy szóval nem mondtam semmi ilyet, de nyugodtan vitatkozz magaddal :)
- A hozzászóláshoz be kell jelentkezni
aki azt hiszi magáról, hogy programozó
Nem vagyok programozó. Hardware fejlesztő vagyok, és meg szoktam írni a firmware-eket a hardware-re.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Igy, de azért nem tartod sokra azt a programozót, aki nem a te szakmád felől közelít egy másikhoz :-)
- A hozzászóláshoz be kell jelentkezni
De nem ezért, hanem azért, mert a programok hardware-en futnak. Tudom, a felsőbb rétegekben már az alsóbb rétegek, kernel, függvénykönyvtárak, az adott nyelv fordítója vagy interpretere elfedi a hardware-t, mégis azt gondolom, hardware-es ismeretek birtokában jobb, gyorsabb, rövidebb kódot lehet írni. Például, mert van az az eset, amikor nincs alattunk kernel, vagy kevés a RAM, lassú a CPU. Egy szemlélet, ha látod magad előtt a memóriát, a struktúrákat, pointereket. Persze lehet úgy, hogy mindent megoldanak a köztes rétegek, meg a fordító, aztán valamikor lefut a valamilyen nagy kód, aminek valamennyire sok RAM-ra lesz szüksége.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
tehat azt mondod, hogy mondjam meg a scala programozoknak akik itt a bigdata "szarokat" rakjak ossze, hogy huzzanak a picsaba, mert nem ertenek a cpu regiszterekhez? Ugyanazzal a svunggal szoljunk a spark fejlesztoinek is????
Azt tudjuk, hogy mondjuk az API-kat irokat/proghranmozokat (Cloud, Kubernetes, whatever) is belevegyuk a "szarfaszu semmihez sem ertok"-hoz?
- A hozzászóláshoz be kell jelentkezni
Ennyire erősen nem fogalmaztam, de szerintem egy mozdonyvezetőnek is megtanítják, hogy mi van a háta mögött. Nem mérnöki szinten, de legyen már képben azzal, hogy mi történik! Autót is akkor tudsz vezetni, ha nem csupán tapasztalatból tudod, hogy ha leugrasz a kuplungról álló helyzetben, akkor lefullad, hanem érted, mit csinálsz, s ezek alapján akkor is ki tudod találni, hogy mit tegyél, ha szokatlan helyzetbe kerülsz. Tudom, nem efelé megy a világ, de én azt egyáltalán nem tartom jónak, hogy ne törődj vele, mi van ott, ezt így kell csinálni, mert ez van a specifikációban. Szerintem ez egy nagyon rossz megközelítés.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Gondolom, a gyerekednek is elmagyarázod, hogy felesleges homokvárat építeni, mert már rengetegen építettek homokvárat.
- A hozzászóláshoz be kell jelentkezni
Azt hiszem, ez a hasonlatféle helyesen úgy hangozna, hogy "más várához akkor építünk hozzá újabb bástyát, ha biztosak vagyunk benne, hogy ezzel nem döntjük romba".
Nekem úgy tűnik, ez az a tanulság, amit a programozó kisfiúknak és kislányoknak le kellene vonniuk ebből az esetből.
- A hozzászóláshoz be kell jelentkezni
Úgy bírom, hogy a sok Rust-huszár próbálja itt osztani az észt!
Na de hány merte elvállalni közülük a bcachefs-tools karbantartását? EGYETLEN EGY SEM. Csak a szájuk jár, ha bizonyítani kell és tettekkel igazolni, akkor lapítanak.
- A hozzászóláshoz be kell jelentkezni
Nyilvan ez igy mukodik, hogy ha valaki elbasz valamit az interneten, azt mindet en csinaljam meg melo meg csalad mellett, hogyne.
Mondom ezt ugy, hogy nem vagyok a Rustban erintett.
- A hozzászóláshoz be kell jelentkezni
Ehhez pár apróság kell csak:
- használja az adott szoftvert (Hány bcachefs felhasználó van a HUP-on? 0-5 közé saccolom, ebből production user 0-1, de inkább 0.)
- legyen Debian Developer (de legalább akarjon az lenni)
- legyen rá ideje
Fentebb le lett írva, hogy nem a Rust miatt van a gond, hanem ahogy a Debian próbálja a Rust alapú szoftvereket kezelni.
Üdv,
ÜRH*
*) Ügyeletes Rust Huszár
- A hozzászóláshoz be kell jelentkezni
Fentebb le lett írva, hogy nem a Rust miatt van a gond, hanem ahogy a Debian próbálja a Rust alapú szoftvereket kezelni.
Na de akkor miért értintett több distro is? A linkről:
at this point you may wonder how any distribution could sanely package this. The problem is that they can’t. Fedora and other distributions with stable releases take a similar approach to what we’ve done in Debian
Összefoglalva: a probléma nem Debian specifikus, Fedora alatt is ugyanilyen szopás a Rust.
- A hozzászóláshoz be kell jelentkezni
Úgy látszik a Fedorában mégis kiügyeskedték valahogy a legújabb verzió csomagjait is számos architektúrára.
- A hozzászóláshoz be kell jelentkezni
Rawhide. Még Fedora 41 sincs, nemhogy 42. :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
ok, de ebbol lesz a dist amikor annyit mondanak, h "most". tehat a lenyegen nem valtoztat. :) "sid-be bekerult mar?" mondasa :D
- A hozzászóláshoz be kell jelentkezni
Az a kérdés, hogy az aktív disztribúcióban a legfrissebb verziószámú utility kerül-e be, vagy mire lesz Fedora 42, a ma legfrissebb, de addigra már régi lesz? Mint ahogy Fedora 40-hez nincs legfrissebb, ki tudja, miért.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
mert igy dontott a csomag/disztro maintainere. aze'.
- A hozzászóláshoz be kell jelentkezni
Oké, én most kezdenék beleszagolni a Rust tanulásba. Ezt viszont nem teljesen értem. Miért olyan nehéz Debian alatt karbantartani egy Rust-ban irt valamit ? Valaki el tudná pár mondatban magyarázni?
“Luck Is What Happens When Preparation Meets Opportunity" - Seneca
- A hozzászóláshoz be kell jelentkezni