• Plusz ami saját, miért lenne jobb? A saját kód is simán eltörhet, lehet szolgáltatáskiesés, lehet benne súlyos biztonsági hiba pont azért, mert saját maga készítette. És mennyi felhasználót képes elérni, ha egymaga fejleszt le mindent, tehát erre sok idő elmegy, ergo kevés új funkciót kap? Szép és jó elképzelés, de valahogy a nagy cégeknek simán kifizetődő pár ilyen incidenst kezelni, ha cserébe nem nekik kell időt és embert fordítani a kialakításra. Nem életszerű, hogy mindig mindent maga fejlesszen ki. Csak az a nem mindegy, kinek a munkáját hogyan becsüljük meg. Végül is az iPhone-t is összerakta a kényszermunkás, nem? Ha nem akarta volna minek ment oda, hadd vegyék már meg és használhassák mások...
    Mutasd a teljes hozzászólást!
  • Ha magamnak csinálok valamit, nem véletlenül nem használok ilyeneket.

    Tehát ha magadnak csinálsz valamit, akkor saját operációs rendszert írsz? Sőt, már a chipeket is Te tervezed és öntöd? Vagy honnan, mitől indul a bizalom?
    Mutasd a teljes hozzászólást!
  • Ja, persze. És persze ha te buildeled le a dockerfájlodat, akkor elõzõleg minden komponens forráskódját átnézed, hogy nincs-e benne valami csúnyaság.

    Volt már rá nem egy példa.

    És persze nyilván kliens oldalon is.

    Az nem az én dolgom.
    Ha magamnak csinálok valamit, nem véletlenül nem használok ilyeneket.
    Ha más azt kéri - övé a balhé, én nem küzdök vele.

    Aztán nyilván ilyenekre nem bíznám a kritikus szolgáltatásaim, meg adataim.
    (Meg a kódjukra se.)
    Mutasd a teljes hozzászólást!
  • Az ÖSSZES licenszben (GNU, BSD, MIT, ...) ott van, hogy AS IS, WITHOUT ANY WARRANTY.Az, hogy ezt esetleg valaki figyelmen kívül hagyja, az legfeljebb slendriánság vagy butaság.

    Hogy viszont ökoszisztémának gúnyolt szemétdombok mellett real life kormányzati vagy pénzügyi szolgáltatások is épülnek erre, az felmérhetetlen szintű felelőtlenség.

    Miért, ha nem lenne ott ez a mondat jobb lenne? Vagy ha azok az alkalmazottak fejlesztenék, akiknél a felelősségvállalás szintén kimerül egy "legjobb tudása, legjobb szándéka" stb kitétel mellett, amit a munkaszerződésükben írnak alá?

    A sw egy fura dolog, amiben nem lehet hibamentességet garantálni, csak azt, hogy legjobb szándékod és tudásod szerint jársz el, amit a munkaszerződésekben is aláír az ember. Nem ingyenes programot áruló cégek se tudnak hibamentességet vállalni, és nem is tudnak felelősséget vállalni az okozott kárért. Főleg nem egy építőkockát beszállító cég esetében, aki a belső céges folyamatot nem is ismeri. 

    Bárki, bármennyire akarja kontrollálni, hogy mire épül a saját programja, teljesen esélytelen a hibákat kizárni. A minőség, stabilitás stb tranzitív jellemzők az egymásra épülés miatt. Amit azon felül tenni lehet, hogy jó megítélésű és bizonyított libeket emelsz be a stackedbe, hogy a stratégiailag fontos OS projectekbe delegálsz fejlesztőket, de ez nem olcsó dolog. A nagy cégek ezzel a lehetőséggel sok esetben élnek is, és ez biztosíték azoknak a cégeknek is, akik az adott projectre épülnek, de nincs anyagi keretük ilyen mértékben bebiztosítani magukat. Ezekből a projectekből hasonló pofon azért nem várható. A contributorok és a processeek átnézése nem butaság az ingyenes OS libek analizálása során. Minden függőség minden commitját nem lehet átnézni, az ilyen átvilágításokkal viszont azért lehet érvelni a várható megbízhatóságról.
    Mutasd a teljes hozzászólást!
  • Ez az egész warranty dolog kb. olyasmikre jó aminek véges sok állapota van. Azaz, egy tégláról meg lehet mondani hogy X kiló a teherbírása, és ha csinálsz 10 ezer téglát azonos anyagból és technológiával, többé-kevésbé magabiztosan bevállalhatod, hogy mind a 10 ezer tégla ugyanannyit fog elbírni. És kb. két állapota van: egy darabban van, vagy eltört. Ehhez képest egy szoftvernek amiben millió feltétel, ciklus, vezérlésátadás van, a viselkedése nem feltétlenül jósolható meg ennyire könnyen. Ok, csinálsz automata teszteket, de minél komplexebb a rendszer, annál kevésbé esélyes hogy _minden_ kombinációt lefedsz. Pláne véges sok fejlesztési költség mellett. Mert lehet mission-critical minõségben is szoftvert csinálni - egy bizonyos komplexitásig - csak annak az árát a Gipsz Jakabka Kft nem tudná kifizetni. Egy atomerõmû gyártási költségében viszont nem számottevõ.
    Mutasd a teljes hozzászólást!
  • Ja, persze. És persze ha te buildeled le a dockerfájlodat, akkor elõzõleg minden komponens forráskódját átnézed, hogy nincs-e benne valami csúnyaság. És persze nyilván kliens oldalon is. Egy Angular az új project létrehozásakor felpakol neked úgy fél giga javascriptet - és tényleg elég érdekeseket, nem véletlenül használtam a csillámpóni.js kifejezést. Az egésznek nekihasalsz, és sorról-sorra átnézed? Sok szerencsét!
    Mutasd a teljes hozzászólást!
  •  A "Vigyáztam!" felkiáltás sem menti fel a furgonost ha tolatás közben átmegy rajtad.


    Sajátos ez a hasonlat..
    A no warranty magában foglalja - jogilag is - azt a koncepciót, hogy valaki a saját cselekedeteiért sem vállal felelősséget. (EDIT: ezt egyébként nem lehetne megtenni jogilag több jurisdikcióban sem, ha magáért a programért kérnél bármiféle ellenszolgáltatást, valóban.)

    Persze lehet vitatni meg elítélni, de ez semmilyen közjogi felelősséget nem alapít.

    Aki meg úgy gondolja, hogy neki jár az, hogy megtalálja a terülj-terülj asztalkámat, annak fel kell hívnom a figyelmét, hogy foied vinom pipafo, cra carefo.
    Mutasd a teljes hozzászólást!
  • Körülbelül annyira veszélyes, mint azokat a programokat felinstallálni. Rámész a gitjére és ott van Dockerfile.

    Igen, ha azt leszeded, átnézed, és az alapján te állítod össze az image-et, az teljesen más, (VS Code-dilemma.)
    A fő gond az, hogy a tutorialos emberkéknek fogalmuk sincsen, hogy hogy működik, amit használnak.

    Ha meg a gépedre felraksz egy Linuxot, akkor már kockáztatsz, mert azzal bármi is felkerülhetett.

    Hát persze..

    A legnagyobb kockázat egyébként a böngésző - hiába open source, ha órákig tart lebuild-elni, a legtöbb security issue nem is publikus, úgy kell kitotózni diffből az esszenciáját a legtöbbször.

    De ne mond hogy a Windowssal nagyobb biztonságban érzed magad.

    Sose mondanék ilyet.

    Ez a srác is ugyanúgy megszívatta azokat is, akik esetleg küldtek neki egy kis pénzt.

    Főleg azokat, akik nem értik az egészet. A többiek 20 sec alatt képesek voltak lockolni az előző verziót (onnantól, hogy felfedezték a probléma esszenciáját).
    Mutasd a teljes hozzászólást!
  • AS IS, WITHOUT ANY WARRANTY

    Erre amúgy kíváncsi lennék, hogy akkor is igaz ha szándekosságról van szó?

    A "Vigyáztam!" felkiáltás sem menti fel a furgonost ha tolatás közben átmegy rajtad. 

    Gondolom, hogy nagyon nehéz lehetetlen lenne bizonyítani a bíróságokon, de elméleti szinten sem lehetne felelősségre vonni (itt vagy Amerikában)?
    Mutasd a teljes hozzászólást!
  • Gondolj bele, hogy hány lángész használ mindenféle docker és egyéb rettenet konténereket hasonló módon prebuilt third party image-ekkel


    Körülbelül annyira veszélyes, mint azokat a programokat felinstallálni. Rámész a gitjére és ott van Dockerfile. Ha meg a gépedre felraksz egy Linuxot, akkor már kockáztatsz, mert azzal bármi is felkerülhetett. De ne mond hogy a Windowssal nagyobb biztonságban érzed magad. Attól hogy valamiért fizetsz, nem lehetsz benne biztos hogy jobbat kapsz. Sőt, a teljes felelősség ugyanúgy a tiéd. Ha feltörik a Windowsod, vagy egy keddi frissítésben odavesznek a dokumentumaid, nem tudod perelni a MS-t. Ez a srác is ugyanúgy megszívatta azokat is, akik esetleg küldtek neki egy kis pénzt.
    Mutasd a teljes hozzászólást!
  • Hát tényleg bármi lehet a valóság, mondjuk még ha el is vesztette mindenét, akkor se ok másokon bosszút állni. De nem is ez a lényeg, hanem hogy meg tudom érteni hogy mennyire frusztrált lett pár ember emiatt a szituáció miatt.

    Én nem.

    Az ÖSSZES licenszben (GNU, BSD, MIT, ...) ott van, hogy AS IS, WITHOUT ANY WARRANTY.
    Az, hogy ezt esetleg valaki figyelmen kívül hagyja, az legfeljebb slendriánság vagy butaság.

    Hogy viszont ökoszisztémának gúnyolt szemétdombok mellett real life kormányzati vagy pénzügyi szolgáltatások is épülnek erre, az felmérhetetlen szintű felelőtlenség.

    És nem, nem magára az open source-ra gondolok, hanem erre az elborult filozófiára, hogy hostolja más, majd betölti a kliens, én nem stresszelem vele magam. Aminek ma része a "cdn js" féle rettenet, ami miatt már siránkoztam itt korábban éppen úgy, mint ez a mai continuous foot shooting (rövidítve: CD) őrület.

    Gondolj bele, hogy hány lángész használ mindenféle docker és egyéb rettenet konténereket hasonló módon prebuilt third party image-ekkel.
    Azt még át se tudod nézni úgy, mint mondjuk egy git tag-et..
    Mutasd a teljes hozzászólást!
  • pl. ugy, hogy nem esz nelkul frissitesz mikor kijon egy uj verzio, hanem vegignyomod a teljes regresszios QA-n, es megoldod az osszes felmerulo problemat vagy visszaallsz az elozo verziora

    Egyetértek.. de ezt a filozófiát már a szifon os-nél érdemes elkezdeni :D
    Mutasd a teljes hozzászólást!
  • Ez mondjuk egyébként a fizetõs kódra is igaz. Nézd meg egyszer a windows felhasználói szerzõdését. De kb. minden épeszû szoftvercég kizár minden anyagi felelõsséget. Egy szoftver nem olyan mint egy vasdarab ahol viszonylag könnyû garantálni hogy ha ráteszel három tonnát akkor kitart, de ha négy tonnát teszel rá akkor elhajlik.

    De az tény, hogy én is jobban megbízok egy .NET frameworkben mint egy-egy javascript framework mögött lévõ millió csillámpóni.js könyvtárocskában.
    Mutasd a teljes hozzászólást!
  • Jogos. Én éppan ma nyitottam egy új projektet, belefutottam, az index.js létrehozása után 1 órával jött elő, majd 5 perc alatt megjavítottam. De valljuk be, egy ncu frissítésben látod, hogy a colors.js patch verziója változott, nem gondolsz arra, hogy teljesen elromlik a színek kezelése??? :) Pláne hogy a colors.js-t inplicite includeoltam be két másik package által: winston->logform->colors illetve mysql-migrations->colors.
    Megoldás: kézzel hozzáadtam a package-ekmez az colors@1.4.0-t.
    Mutasd a teljes hozzászólást!
  • Ez a regi vesszoparipam az open source-val es a community fejlesztessel kapcsolatban: mikor felhasznalod, akkor tudatositanod kell magadban azt, hogy 1) mivel ingyenes, a karbantarto(k) semmilyen anyagi felelosseget nem vallalnak az eredmenyert. Erkolcsit esetleg, de azzal nem tudsz sokat kezdeni amikor a derivativ kereskedelmi megoldasod bedol es emiatt az uzleted kart szenved. Es 2) nem biztos, hogy a karbantarto jogi ertelemben egyaltalan felelossegre vonhato a hiba miatt. Bugos a kod? Istenem, mindenki tevedhet... neadjisten, tobben voltunk es a merge miatt nem mukodik. Ezek ugyan szakmailag nagyon gyenge ervek, de senki sem irja elo a kotelezo minimalis szakmai szinvonalat.

    Ezzel egyutt is, van amikor jo alternativa nyilt/kozossegi kodbazisra epiteni a kereskedelmi termekedet, csak a fenti kockazatokat kezelni kell (pl. ugy, hogy nem esz nelkul frissitesz mikor kijon egy uj verzio, hanem vegignyomod a teljes regresszios QA-n, es megoldod az osszes felmerulo problemat vagy visszaallsz az elozo verziora). 


    Lehetne azzal ervelni, hogy aki letrehozott egy megoldast, az felelos erte, de valojaban ez nem igy van. Nekem is van git repom, nem mukodik a kod, nem erdekel. Ugyanakkor viszont alsagos azzal jonni hogy a fortune500 miert nem fizet neki - o hatarozott ugy, hogy ingyen adja a megoldasat, ez azt jelenti hogy nem kell fizetni erte. Elon Musknak meg Jeff Bezosnak sem, pedig nekik aztan van penzuk. Valaszthatott volna mas licenszelesi modot, letrehozhatott volna parhuzamos, fizetos verziot a nagyvallalatoknak es deprecated-be tehette volna az ingyenes verziot, lattunk mar ilyet. Olyan ember is van, aki a jo otletre felhuz egy uzleti tervet, befektet nemi toket es csinal startupot, aztan ha a termek tenyleg jo, majd fizet erte a fortune500 (vagy ha megse jo otlet, akkor elbukja a befekteteset). 

    A hiszti meg az alaptalan kovetelozes viszont olyan dolog, ami miatt nehez komolyan vennem a maintainert. Az meg, hogy ezt ugy eli ki hogy becsekkel egy nem mukodo verziot, teljesen beleillik a gyerekes viselkedesebe. A milliok, akik szivtak miatta, remelem hamar rajottek hogy egesz egyszeruen vissza tudnak allni az utolso verziora, es mar gondolkodnak azon hogy talan egy erettebb gondolkodasu fejleszto csomagjara valtanak...
    Mutasd a teljes hozzászólást!
  • Nem kimondottan a verzióra gondoltam, hanem arra a lib mennyiségre, amit alapból lehúz egy zöldmezős Angular project. Több ezer forrás állomány, kb. 350MB. Persze ezt lehet csökkenteni, ahogy @pank is írja, de ahhoz alaposan át kell nézni mindet, hogy mégis mi az, amire nem lesz szükség, és mit kell megtartani. A frissítés nyilván nem opció egy éles rendszer esetében, azt mindig a fejlesztői környezetben kell első körben tesztelni.
    Az alapvető probléma az, hogy ezekben a letöltött lib-ekben nagyon sok olyan független fejlesztő munkája is benne van, amiről azt sem tudod, hogy mit csinál, és hogyan. Az meg eléggé hosszadalmas, hogy mindet tüzetesen átnézz, és utánaolvass.
    Mutasd a teljes hozzászólást!
  • Sztem jobb különszedni a package updater release-ket a feature releasektől.
    Tegyük fel DB migration kell az új feature-nek, majd probléma van a prod-on a kiment kóddal, azután, hogy a teszteléseken és többi szervereken már végigment, viszont azokon nem volt elég adat vagy olyan jellegű adat/valamilyen oknál fogva bizonyos cucc nem volt lefedve tesztelés során, a DB update-et már nem lehet rollback-elni.
    Mutasd a teljes hozzászólást!
  • Pont az npm esetén megmondhatod hogy melyik verzióját használod a csomagnak. Az nem úgy van hogy automatikusan frissül. Ez pont olyan mint amikor a dockerfile a latestre hivatkozik. Nem csak abból lehet gond, ha valaki szándékosan ártani akar.
    Én úgy szoktam, hogy egy nagyobb fejlesztés elején frissítek és a végén azzal megy ki. Mire elkészülök a kóddal, addig több ezer alkalommal tesztelve lesz. De olyat el se tudnék képzelni hogy az éles kódot automatikusan frissítem, és mindenféle tesztek nélkül kiraknám. Még egy súlyos biztonsági hiba esetén is legfeljebb csak azt a csomagot és erősen átnézve/tesztelve.
    Mutasd a teljes hozzászólást!
  • Igen. Hát tényleg bármi lehet a valóság, mondjuk még ha el is vesztette mindenét, akkor se ok másokon bosszút állni. De nem is ez a lényeg, hanem hogy meg tudom érteni hogy mennyire frusztrált lett pár ember emiatt a szituáció miatt. És csak mert az egyik fél hibás, lehet a másik fél is az.
    Mutasd a teljes hozzászólást!
  • Fent van még az archive.org-on. És nem csoda, hogy nem nyilvános már. ;D
    Mutasd a teljes hozzászólást!
  • Nem atomfizika a nem használt libek eltávolítása sem. De ha az angular túl heavy, ott a vue.
    Mutasd a teljes hozzászólást!
  • Nem is úgy gondoltam, hogy visszamenőleg.

    A licencet sem változtathatja meg visszamenőleg. Ha kiadott valamiből egy ingyen felhasználható verziót, akkor arra már nem mondhatja, hogy mégis fizessetek érte. Vagy senki ne használja.
    Mutasd a teljes hozzászólást!
  • 1. sztem ez egy ismert probléma, bármikor megtörténhet - ezért is szoktak bankok saját package-eket írni néha ahelyett, hogy meglévőket használjanak.
    2. sztem simán módosíthatta volna a liccenszt, és fizetőssé tehette volna igényei szerint
    3. ami szerintem inkább érdekes, hogy az a rengeteg fejlesztő ahányan ezeket a public repo-kat létrehozzuk és felelősségteljesen gondozgatjuk az figyelemre méltó.
    Mutasd a teljes hozzászólást!
  • Törölhette volna a könyvtárát.

    Nem igazán. A left-pad fiaskó óta az NPM-ből nem engednek törölni olyan csomagot, amitől másvalaki függ: npm Unpublish Policy

    A forráskódot tartalmazó git repót törölhette volna, csak az a kutyát nem érdekli, ha a kód fut tovább.
    Mutasd a teljes hozzászólást!
  • Ilyet akkor sem csinálhat.

    a) Törölhette volna a könyvtárát.

    b) Módosíthatta volna a licencelését a következő verziótól kezdve.
    Mutasd a teljes hozzászólást!
  • Jó eséllyel ez a frissített verziója annak, amit linkelni próbáltál. A kommentekben azt írták, az a ház leégés nem is úgy volt, hanem a saját hibájából történt, meg egyébként is volt már dráma e körül az ember körül.

    Én nem fogom megpróbálni kitalálni hogy kinek van itt igaza, főleg hogy az interneten mindenki azt mond amit nem szégyell, de úgy néz ki nem fekete-fehér a dolog.
    Mutasd a teljes hozzászólást!
  • Kicsit tágabb és más hangvételű nézőpont:
    - YouTube
    Edit: eh most látom priváttá tette a videót a feltöltő. :(
    Röviden arról szólt, hogy mennyire nem foglalkoznak a nyílt forráskódú projektek finanszírozásával, viszont az előnyeit kiélvezik a nagy cégek is. Könnyű támadni valakit, mert szerzői jogot sértett, viszont lehetetlen támadni valakit, mert nem fizet egy nyílt forráskódú projektért. Itt a videó feltöltője szót ejtett általánosságban a tudás szabad terjesztése témaköréről, ami kényes téma pl. akadémiai területen, és néhányan közzéteszik a publikációkat, mert céljuk, hogy szabad legyen a tudás, persze beperelik őket. De ki pereli a top500 céget, mert a profitját nem osztja meg a nyílt forrású szoftverek tulajaival? Senki, elvégre, minek tette közzé ugyebár. Csak el kéne gondolkodni arról, hol is tartanánk ha nem lennének ingyenes könyvtárak, és mennyire nem foglalkozunk mások munkájának jutalmazásával.
    Aki módosította a kódot, annak leégett a háza, minden vagyona. Több tízezer, millió ember függött a munkájától, mégis annyira nem volt semmi értéke az írásának, annyira semmi támogatást nem kapott, hogy tele lett a hócipője. Én teljesen megértem, elveszettnek érezte magát. Nem tetszik, hogy elromlott egy nyílt forráskódú könyvtár? Egyszerű: írd meg magad. Mint ahogy a kódot se kötelező ingyen közzétenni, úgy felhasználni sem az.
    Mutasd a teljes hozzászólást!
  • Az JS és az npm világában épp az az egyik legnagyobb probléma - és az ezeket a függőségeket használó technológiákkal - hogy itt boldog, boldogtalan, Vér Pistikéktől a Google-ig mindenki azt teszt be, amit akar, aztán mineki ezekre építi fel a szoftverét. Például itt van az Angular. Trendi, elterjedt, mindeki odavan érte, de azért mégis, kb. 360MB-os npm sz**rt letölt csak ahhoz, hogy fejleszhess vele. Minek? Én már nagyon sokszor néztem a lehúzott kódokat, egy átlagos Angular-os frontend project során a negyedét nem használod annak a sok lib-nek.

    Ennél már egy-két fokkal megbízhatobb a Java világában a maven repo, ott legalább lib-enként megmondhatod, hogy mit húzól be, és mit használsz fel. Az meg már egy másik dolog, hogy ott legalább az elterjedt és sokak által általánosan használt függőségeket alapítványok (pl.: Apache, Eclipse) és nagyobb cégek fejlesztik.

    Az viszont eléggé világos, hogy ha valaki publikálja a forráskódját nyilt formában, akkor ne kezdjen el később sírni azért, mert nem kap érte pénzt. Az már teljesen mindegy, hogy a felhasználó egy profit orientált nagy cég, vagy egy hobbi programozó. Az viszont nem elfogadható, hogy valaki szándékosan elrontja a kódját, azért, hogy kvázi ezzel zsarolhasson, mert rájött, hogy a kódjából más pénzt tud csinálni. Kérjen támogatást, vagy ha ez nem megy, akkor legyen fizetős a lib, de ezt is persze jó előre bejelentve, hogy senkit ne érjen meglepetésként. Aztán meglátjuk, utána mire megy vele. Ha annyira jó a lib, akkor fizetni fognak érte, ha meg nem, akkor örüljön a "hírnévnek". Most biztos, hogy népszerű lett, ezzel a lépéssel elég jól elrontotta az alkupozicióját.
    Mutasd a teljes hozzászólást!
  • Tegye fel a kezét, aki szerint jó ötlet automatikusan behúzni egy újabb verziót egy függőségből. Talán az egyetlen kivétel, ha security problémát javít.
    Mutasd a teljes hozzászólást!
  • Az persze más kérdés, hogy milyen licensz volt megadva és egyáltalán van e olyanra lehetőség mint pl a Visual Studio, hogy X bevétel esetén válik fizetőssé.

    Tudtommal attól, hogy feltöltesz valamit a Githubra, még teljes mértékben nálad marad a szerzői jog, tehát továbbra is te döntöd el hogy ki mire használhatja. (Akár licenszszerződéssel, vagy megtartva a szerzői jog alapesetét, vagyis hogy mindenkinek egyesével kell engedélyt kérnie.)

    Amúgy a pénzügyi vonzat mellett szerintem érdekes a dolog bizalmi vonzata is. Amikor felhasználsz egy külső kódot, implicit megbízol a fejlesztőiben, hogy nem raktak bele ártó szándékú részt. Ha emellé még engedélyezed az automata frissítést is, akkor bízol abban is, hogy a jövőben se fognak ilyet csinálni. Mint a fenti példa mutatja, ezekre a dolgokra nincs garancia, csak a szokás, hogy nem tolunk ki egymással. Valószínűleg jópár project ezek után alaposabban meg fogja gondolni, mikor upgrade-el, és mennyit tesztel az upgrade után.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd