Biztonságosabbak a PHP-ben és a Perl-ben, mint a .NET-ben és a Java-ban írt weboldalak
2014-04-16T13:59:27+02:00
2015-03-05T17:23:07+01:00
2022-06-29T14:32:01+02:00
  • És újra!
    Sok oldalt látok, és szörnyülködöm a biztonságon...
    Tényleg ilyen katasztrofális a helyzet vagy csak én nyúlok bele ezekbe az oldalakba.
    Mutasd a teljes hozzászólást!
  • Lusta vagyok végig olvasni a teljes vitát, de szerintem értelmetlen is...
    Minden weblap pont annyira biztonságos, mint amennyire biztonságosnak megírják.
    Minden program nyelvnek vannak gyenge pontjai, amikre figyelnie kell a fejlesztőnek.
    De ennek ellenére is a leggyengébb láncszám a biztonsági részen maga a programozó.
    Mutasd a teljes hozzászólást!
  • Hosszú távon és nagy méretekben ennek a gyakorlatban nincs jelentősége. Minek akarnál megküzdeni egy olyan problémával, ami nem a te dolgod? Amiről te beszélsz, az a szocialista autó: miután hazavitted, még bütykölni kell rajta, hogy jó legyen. Meg utána is állandóan. Mások meg úgy vannak vele, hogy a saját munkájukban és tevékenységükben jobbak, mint az autószerelésben/-gyártásban, ezért ez utóbbit meghagyják az autógyárnak (hogy megbízható, azonnal működő autójuk legyen) meg az autószervizeknek; és az így felszabaduló idejüket arra használják, ami meg az ő dolguk. Ha tőled megrendelnek egy terméket, akkor az ügyfeled nem biztos, hogy javítgatni akarja a kódodat később, ha hiba van benne. Mert aztán ha te nem érsz rá, vagy épp már kávézót nyitottál, mert ráuntál a programozásra, akkor elég macerás neki keresni valakit, aki megoldja a problémáját. Itt meg tökmindegy, hogy kintről, vagy bentről kell embert keresnie rá.
    Mutasd a teljes hozzászólást!
  • Ha neked még az felhasználói program hibáin túl még az alap frameworkben is vadászni kell a bugokat, akkor régen rossz. Egyrészt, mert nagyságrendileg meg tudja dobni a nyomozás időtartamát, másrészt mert egy ilyen kód belül néha elég bonyolult tud lenni. Ezért aztán tanácsos olyan kódot használni amiben egyrészt gyárilag nincs túl sok hiba - márpedig Pl. a .NET fw elég megbízható e téren - másrészt amit sokan használnak, így ha valamivel valami gond van, az jó eséllyel másnál is szembejön, és gugli barátunk segíthet.
    Mutasd a teljes hozzászólást!
  • Nem, szerintem csak annyit állított hogy a mérhetetlen kétségbeesés és tehetetlenség és egymásra mutogatás helyett esetleg megpróbálhat megküzdeni a problémával egyedül is. Nem állítja senki sem hogy könnyű, de hogy a forráskód birtokában lehetetlen? Egyébként, sok esetben, így is kénytelenek lesznek megírni az alap platformot, de a forráskód hiányában nulláról.
    Mutasd a teljes hozzászólást!
  • hanem ha már senki más nem, akkor saját maguk nekiállhatnak megkeresni és kijavítani a hibát az alapplatformban is

    Tehát nem elég, hogy fejleszted az X termékedet, elkezdesz fejleszteni egy másik Y-t, amit eredendően nem is a saját csapat fejlesztett. Az Y-on végzett munkát aztán lehet ütemezni, meg embert felvenni rá. Ritkán akarja ezt csinálni bárki is.
    Mutasd a teljes hozzászólást!
  • és minden más téget segítő infó, ami a fejlesztési fázisban nyűg volt odaírni

    Ilyen pl. a referenciák típusa, amit aztán az IDE számos hasznos működésre fel tud használni.
    Mutasd a teljes hozzászólást!
  • Ami hogy teljesül -e, nem az alapplatform forrásának nyíltságától vagy zártságától függ. Ezt már egy párszor megbeszéltük.

    Az általad fejlesztett kódé valóban nem. De hogy jön ez most ide ?

    Ez pont a nyílt forrású megoldások mellett szólna, hiszen csakis azok esetében nincsenek kiszolgáltatva a menedzser és a fejlesztői a gyártó kényének és kedvének, hanem ha már senki más nem, akkor saját maguk nekiállhatnak megkeresni és kijavítani a hibát az alapplatformban is.

    Ha az alapplatformban van a hiba az már régen rossz. Ezért törekszenek a managerek olyan platformra alapozni, ahol ez kevésbé valószínű, és főleg olyanra amire lehet mutogatni, ha mégis.

    A folyamat végén mindig a fejlesztőnek jut ki. Én még nem láttam olyant, hogy egy projekt menedzser vagy magasabb szintű vezető beleállt volna egy bukásba

    Ha egy nagy projekt bukik, ott nem a fejlesztő lesz elsősorban fenéken billentve. Más kérdés, hogy nem is az a manager aki az egészért leginkább felelős.

    Miért, a kód karbantartása nem kódolás maga is legalább akkora részben, mint eredetileg is volt?

    Nem. Alapvetően két, egymástól elkülönülő folyamatról van szó. A fejlesztés fázisában sok kódot írsz le, viszonylag gyorsan. Pontosan tudod, hogy mit akarsz, minek hogy kellene működni, mi miért van úgy ahogy van. Leírsz naponta több száz sort. Ebben a fázisban neked az a jó, ha minél tömörebb a nyelv, minél kevesebbet kell gépelni. Itt lehet sokat spórolni az egybetűs változónevekkel, commentek elhagyásával, és más hasonló "kreatív" megoldásokkal. Más kérdés, hogy később mennyire fáj majd ez.

    Aztán eltelik mondjuk 3 év, és előjön egy hiba. Ekkor jön a support. Neki már a legjobb esetben is csak a rendelkezésre álló dokumentumok vannak, plusz a felkommentezett forráskód, és egy-két elszórt nyom az adatbázisban ami arra utal, hogy mégis mi történhetett. Ezt a nyomot azonban rossz esetben 4-5 különböző folyamat is hagyhatta. Neked ez alapján kell megérteni hogy mit, miért csinált 3 éve, és ez vajon milyen körülmények esetén okozhatta azt ami történt. Itt van átlagban olyan 2 nap nyomozás, és a végén módosítasz 5-10 sort a kódban. Ebben a fázisban viszont aranyat érhet az a comment és minden más téget segítő infó, ami a fejlesztési fázisban nyűg volt odaírni. Ami a fejlesztésnél kb. 20 másodperc plusz idő, az ebben a fázisban órákat, sőt akár napokat spórolhat meg.

    Minden a szoftver életciklusától függ. Más a jó akkor, amikor magamnak írok egy 100 soros scriptet egyszeri használatra, és más az amikor tudom, hogy a szoftver amit csinálok, jó eséllyel még 20 év múlva is velünk lesz, és addig folyamatosan supportálni kell.
    Mutasd a teljes hozzászólást!
  • A menedzser hátsó fele általában akkor van biztonságban, ha megbízható, átlátható, karbantartható a kód.

    Ami hogy teljesül -e, nem az alapplatform forrásának nyíltságától vagy zártságától függ. Ezt már egy párszor megbeszéltük.

    Ha bejön egy olyan súlyos hiba, amivel X napon belül nem tud mihez kezdeni az alsó szintű support (ahol X a dolog súlyától függ), akkor a hátsók igen heves rugdosása következik be és az sok-sok managernek fáj.

    Ez pont a nyílt forrású megoldások mellett szólna, hiszen csakis azok esetében nincsenek kiszolgáltatva a menedzser és a fejlesztői a gyártó kényének és kedvének, hanem ha már senki más nem, akkor saját maguk nekiállhatnak megkeresni és kijavítani a hibát az alapplatformban is.

    És persze a folyamat végén kijut a fejlesztőnek is.

    A folyamat végén mindig a fejlesztőnek jut ki. Én még nem láttam olyant, hogy egy projekt menedzser vagy magasabb szintű vezető beleállt volna egy bukásba - akkor sem, ha az egyértelműen az ő hibájából következett be (ahogy az általában lenni szokott). Az ilyen emberek ha el is kerülnek, akkor is általában felfelé buknak, szervezeten belül és cégek között is.

    Nem ez volt a szándékom, csak annak a hangsúlyozása, hogy egy nagy cégnél egy fontos projektben a kódolásra fordított idő nem igazán a fő szempont. Sokkal lényegesebb, hogy a dolog utána mennyire tartható karban hosszú távon.

    Miért, a kód karbantartása nem kódolás maga is legalább akkora részben, mint eredetileg is volt?
    Mutasd a teljes hozzászólást!
  • A menedzser hátsó fele általában akkor van biztonságban, ha megbízható, átlátható, karbantartható a kód. Ha bejön egy olyan súlyos hiba, amivel X napon belül nem tud mihez kezdeni az alsó szintű  support (ahol X a dolog súlyától függ), akkor a hátsók igen heves rugdosása következik be és az sok-sok managernek fáj. És persze a folyamat végén kijut a fejlesztőnek is.

    Ráadásul megint azt sugallod, hogy PHP/Ruby/Python-ban nem lehet átlátható, megbízható, karbantartható kódot írni.

    Nem ez volt a szándékom, csak annak a hangsúlyozása, hogy egy nagy cégnél egy fontos projektben a kódolásra fordított idő nem igazán a fő szempont. Sokkal lényegesebb, hogy a dolog utána mennyire tartható karban hosszú távon.
    Mutasd a teljes hozzászólást!
  • Kezdve ott, hogy a gombot hová teszed fel, hogy más gombokat ne zavarjon be? Olyanokat se, amiket Te nem látsz, mert nálad nincs a Te jogosultsági szinteden vagy a Te licenceddel.

    Van amit nem kell túlbonyolítani. Adott egy vállalati intranet oldalon a telefonkönyv, amelyen már van megfelelő jogosultsági rendszer, hiszen máskülönben a névjegyet meg se mutatná. Nem kérdés, hogy ha már odaáig eljutottunk, hogy html-be lerendereli (azaz megmutatja) a kérdéses adatokat, akkor az adatokhoz való hozzáférés stb. kérdése meg van oldva.

    Egy olyan funkció, hogy mindezt küldje is át SMS-ben, már nem kíván további jogosultsági stb. döntéseket, mivel az adatok egyébként is meg vannak jelenítve, ergo ha akarom kézzel kiírom őket vagy lefotózom, ennyi.

    Az is by default benne volt a rendszerben, hogy a megjelenített névjegynek küldjön SMS-t az én számomról (!), mivel volt a telefonszáma mellett egy ilyen gomb. Ergo tényleg nem kellett volna már semmi, csak egy árva gombot odabiggyeszteni és megírni hozzá kemény 30 perc programozás árán a funkciót.

    Ami meg az oldal vizualitását illeti, hadd ne minősítsem, egy gomb oda vagy vissza nem zavarta volna meg a layoutot... (Egyébként is egy jó layout bármikor elbír ±1 gombot.)

    Mondom még egyszer, vállalati intranet oldalról beszélünk, amely létének az egyetlen értelme, hogy a munkát segítse.
    Mutasd a teljes hozzászólást!
  • Ehhez nem kell külső tanácsadóval hatástanulmányokat készíttetni meg board szinten dönteni

    Dehogy nincs.
    Kezdve ott, hogy a gombot hová teszed fel, hogy más gombokat ne zavarjon be? Olyanokat se, amiket Te nem látsz, mert nálad nincs a Te jogosultsági szinteden vagy a Te licenceddel.
    Mutasd a teljes hozzászólást!
  • Ha van egy jo otletem, azt 3-4 szinten meg kell beszelni, felmerni a kockazatokat a kulonbozo rendszerek kozott, tesztelni tobb szinten stb, stb... A kodolas (neha 2 sor) a legkevesebb...

    Ok. Az ötlet az volt, hogy az intraneten működő céges telefonkönyvben legyen egy gomb, amelyet ha megnyomsz, a kontaktot automatikusan elküldi a telefonodra SMS/MMS formátumban, hogy ne kelljen egyenként és soronként begépelnem a kontaktot telefonomba. (Név, mobilszám, vezetékes szám, e-mail stb.) Egy ilyen funkció nem módosít semmit semmilyen adatbázisban, egyszerűen csak a már amúgy is lekért és megjelenített rekordokat átküldi egy másik struktúrában SMS-ben. Ehhez nem kell külső tanácsadóval hatástanulmányokat készíttetni meg board szinten dönteni -- viszont rengeteg ember napi munkáját könnyítette volna meg.
    Mutasd a teljes hozzászólást!
  • Ott igazából nem annyira nagyon az számít, hogy mennyire gyorsan kódolják le a dolgot, sokkal inkább az, hogy a lekódolt dolog átlátható, megbízható, karbantartható legyen, és ha elmegy az X ember és helyére jön az Y, akkor záros határidőn belül magabiztosan tudjon dolgozni a rendszeren.

    Ezért megint kapsz Stingtől, ha még nem unta meg Már többször levezette, sőt Te is kijelentetted, hogy nem az átlátható, megbízható, karbantartható kód számít, hanem a menedzser hátsó fele... Ráadásul megint azt sugallod, hogy PHP/Ruby/Python-ban nem lehet átlátható, megbízható, karbantartható kódot írni.
    Mutasd a teljes hozzászólást!
  • De meg mennyire igy van :)
    Ha van egy jo otletem, azt 3-4 szinten meg kell beszelni, felmerni a kockazatokat a kulonbozo rendszerek kozott, tesztelni tobb szinten stb, stb... A kodolas (neha 2 sor) a legkevesebb...

    Enterprise kornyzetben a kockazatot a leheto legkisebb mertekure kell redukalni. Mindent meg kell vizsgalni, az osszes hatast, mellekhatast, risket, business flow-t stb, stb. Annyi mindent, hogy minden egyes modositas is akar honapokat vehet igenybe. Egy konnyelmu dontes neha elkepeszto karokat tud okozni, akar olyan is, ami teljesen trivialisnak latszik... (klasszikusan ugye van egy meta field, amit "senki nem hasznal", csak 8 rendszerrel arrebb valaki, addig csak utazik es nincs, aki ezt atlatna...)

    Meg kell nezni egy bankot, hogy ott hogy megy es megerteni, hogy miert lomha monstrumok - de mukodnek.
    Mutasd a teljes hozzászólást!
  • Teljesen mindegy, hogy EJB vagy PHP vagy gw-basic lett volna a fejlesztés nyelve. Ez ugyanis nem ezen múlik. Enterprise esetén általában van egy szép nagy hibajegy kezelő rendszer, amiben szépen ott sorakoznak a hibák, súlyosság és fontosság szerint priorizálva, illetve a fejlesztési kérések ugyancsak fontosság szempontjából priorizálva (mondjuk ez egyébként tisztességes helyen amúgy is így van). Ezen kívül még ott vannak a hosszú távú fejlesztések, illetve ha külsős fejlesztő cég van, akkor a cég egyéb projektjei. Azaz egy számodra ugyan jónak tűnő, de másnak nem feltétlenül lényeges feature requesttel elég jó eséllyel a tápláléklánc legalján fogod találni magad. Különösen, ha szép hosszú a backlog, és nagyon kevés rá a fejlesztő.

    A másik dolog, hogy egy-egy szoftvernek lehetnek hosszú távú fejlesztési stratégiái is, amibe a kérés nem feltétlenül illik bele. Pl. olyan alrendszeren akarsz fejlesztést aminek a leváltására szolgáló szoftveren már fél éve dolgoznak.
    A harmadik - és egyben a legfontosabb - része a dolognak, hogy feature requestet általában üzleti döntés alapján fogadnak be. Azaz nem a mezei fejlesztő fogja eldönteni, hogy az adott dolgot lefejlesztjük vagy sem, hanem az üzlet mondja meg, hogy ezt a fejlesztést mi finanszírozni akarjuk-e vagy sem.

    És amúgy lehet, hogy szerinted az csak egy fél óra fejlesztés, de néha csak a hibajegy körüli adminisztráció fél óra - és akkor még hozzá se nyúltál a feladathoz. Másrészt, a feature request általában funkcionális változást is jelent - és mivel egy-egy ilyen rendszer egy bizonyos specifikáció alapján kell hogy működjön (ez alapján dől el hogy valami bug vagy feature ) így ha ezt megváltoztatod, akkor ezt a specifikációt is módosítani kell. Ami úgy működik, hogy írsz egy javaslatot a specifikáció módosítására, ezt el kell fogadja először a vezető programozó, majd pár manager az üzleti oldalról (2-3 nap alsó hangon, de csak abban az ideális esetben, ha a szoftver csak egy cégnek készül). Ha minden Ok, akkor módosíthatod a specifikációt, és utána kezdhetsz el a dologgal foglalkozni. És ez néha még a durva leegyszerűsítése a folyamatnak... Ennek nem az a költsége, hogy odaírsz plusz 50 sort a kódba.

    Enterspájznál nem úgy működnek a dolgok sajna, hogy nekiállsz a programnak és csak úgy módosítod. Persze, ha találsz egy bugot ahol egyértelmű, hogy a progi nem a speckónak felel meg, az Ok. De egy fejlesztés már nem ilyen.
    Mutasd a teljes hozzászólást!
  • Valószínűleg ha nem EJB-ben lett volna megírva a vállalati intranet (ami egyébként lassú volt és merev és semennyire se felhasználóbarát), hanem mondjuk PHP-ban

    Ez miből következik? PHP-ban nem lehet monstre rendszereket csinálni?
    Mutasd a teljes hozzászólást!
  • Egy 10 emberórás projektnél esetleg számít, hogy mennyire gyorsan kódolsz. Egy 10 emberévesnél már kevésbé.

    Ez tényleg így van, de erről eszembe jutott egy pár évvel ezelőtti történet. Küldtem egy kérést a vállalati intranet fejlesztőknek, amit én magam is meg tudtam volna oldani max. 30 perc alatt, de akkor ebben a kávézás is benne lett volna.

    Visszaírtak, hogy jó ötlet, de belátható időn belül nem lesz erőforrás a fejlesztésre.

    Csak azt a hibát követte el a csaj, hogy a levelében benne felejtette a belső levelezést a főnökével, kb. arról, hogy "most erre milyen kifogást írjak? -- válasz: nem tudom, írj valamit ami hihetőnek hallatszik".

    Valószínűleg ha nem EJB-ben lett volna megírva a vállalati intranet (ami egyébként lassú volt és merev és semennyire se felhasználóbarát), hanem mondjuk PHP-ban, és normális fejlesztők ültek volna a szerkesztőségben, akkor az ilyen kéréseket seperc alatt lefejlesztették volna.

    Szóval nyilván megvan a helye a robosztus enterprise rendszerekben a Javának/.NET-nek, de nem biztos, hogy minden verébre ezzel az ágyúval kellene lőni.
    Mutasd a teljes hozzászólást!
  • Persze hogy elkezdik. Ahogy a ruby-s, pythonos, php-s projekteket is. Csak jellemzően nem az enterprise szféra. Ott igazából nem annyira nagyon az számít, hogy mennyire gyorsan kódolják le a dolgot, sokkal inkább az, hogy a lekódolt dolog átlátható, megbízható, karbantartható legyen, és ha elmegy az X ember és helyére jön az Y, akkor záros határidőn belül magabiztosan tudjon dolgozni a rendszeren. Egy 10 emberórás projektnél esetleg számít, hogy mennyire gyorsan kódolsz. Egy 10 emberévesnél már kevésbé.
    Mutasd a teljes hozzászólást!
  • Hát pedig valakik csak el kezdik a Clojure, Scala, F# stb. projekteket, azaz ráveszik valahogyan a menedzsmentet, hogy xy nyelvben jobban/gyorsabban lehetne fejleszteni, és ez által némi versenyelőnyre lehet szert tenni a mezítlábas Java/C# fejlesztőkkel szemben, nem?

    Így van ez a PHP, meg keretrendszereivel is. Komplex esetekben nehéz ám bizonyítani, hogy ki dönt pusztán szakmai, vagy nem pusztán szakmai indokokból. Pl. amikor valakinek vannak ilyen-olyan, hibás elképzelései az Oracle v. MS keretrendszereiről, vagy akár a dinamikus nyelvekről. Meg amikor azért választja mondjuk a PHP-s keretrendszert, mert hogy a PHP Turing teljes és elvben bármit lehet rá cross compile-olni.

    Én csak olyat láttam testközelből, hogy különböző vállalati csoportoknak különböző platformok voltak a "gyermekei" (azaz ebben volt tapasztalatuk, ezt építgették évek óta), és a platformok közötti harc a vállalati csoportok közötti harcban manifesztálódott.

    Előfordulhat. Persze aztán ritkán fordul elő, hogy kirúgnak 100 Javás embert, hogy 100 PHP-st vegyenek fel a helyükre 1 hónapon belül, mert a PHP-s keretrendszer látszólag jobban passzol az új projecthez. No és hát előfordulhat, hogy _tényleg_ jobban passzol. De az élet már csak ilyen. Bonyolult dolgok ezek, aztán nem lehet mindig jól dönteni. Néha még utólag is nehéz megmondani, hogy mi az, hogy "jó". Mihez képest? Honnan nézve?
    Mutasd a teljes hozzászólást!
  • csak olyan komponenst használsz, mint ami a stackben van, akkor pár nap alatt át lehet venni a munkádat

    Hát pedig valakik csak el kezdik a Clojure, Scala, F# stb. projekteket, azaz ráveszik valahogyan a menedzsmentet, hogy xy nyelvben jobban/gyorsabban lehetne fejleszteni, és ez által némi versenyelőnyre lehet szert tenni a mezítlábas Java/C# fejlesztőkkel szemben, nem?

    Én csak olyat láttam testközelből, hogy különböző vállalati csoportoknak különböző platformok voltak a "gyermekei" (azaz ebben volt tapasztalatuk, ezt építgették évek óta), és a platformok közötti harc a vállalati csoportok közötti harcban manifesztálódott.

    A kedvencem amikor a top menedzsment annyit vélt csak érteni az egészből, hogy "HTML5", és ettől kezdve minden egyes diára rá kellett írni legalább egyszer a HTML5-öt mivel akkor a top menedzsment elhitte.
    Mutasd a teljes hozzászólást!
  • Használj egy olyan nyelvet vagy frameworköt, amihez kevesen értenek

    Mint pl. Java/J2EE, vagy C#/ASP.NET? Ha j2ee-ben csinálsz valamit és csak olyan komponenst használsz, mint ami a stackben van, akkor pár nap alatt át lehet venni a munkádat. Pont ez az az egyik előny, amiért azon hátrányokkal fizetsz, amiket egyébként joggal tulajdoníthasz neki.
    Mutasd a teljes hozzászólást!
  • nem azért választja a bank sem a multitól származó megoldást a nyílt forráskódú helyett, mert előbbi technológiai szempontból jobb, biztonságosabb vagy mert nagyobb eséllyel fog X év múlva is létezni és fejlődni. Hanem mert az ottani vezető karrierista, és tesz arra, hogy technológiai szempontból, illetve a cégnek melyik a jobb. Őt ehelyett csak az érdekli, hogy neki személyesen, mint üzletembernek melyik a jobb - azaz, melyiknél jattol neki zsebbe a multi, és melyiknél lehet mutogatni másokra, ha valami balul sül el.

    Pont ez az, ami izgat engem. Hogy a személyes érdekek, nézetek sokkal többet számítanak a platform választásában, mint a racionális meggondolások.

    Ugyanez egyébként nem csak a menedzsmentre vonatkozik, hanem jóformán mindenkire. A projekt menedzserekre, az architectekre, de még az egyszeri kóderekre is, gondolom én.

    Be akarod biztosítani a helyedet, hogy ne lehessen könnyen lecserélni? -- Használj egy olyan nyelvet vagy frameworköt, amihez kevesen értenek, és nyugodtan túrhatod a Julia, Erlang, Clojure stb. programjaidat életed végéig.

    Fejlődni akarsz / meg akarsz tanulni egy új nyelvet? Győzd meg a főnöködet, hogy a következő projektet sokkal jobb Elixirben megírni, és máris Elixirezhetsz kedvedre.

    Jó lenne körülnézni kicsit Miamiban? A M$/Oracle pont ott tartja az új platformjának menedzsment tájékoztatóját, és szívesen kivisznek pár hétre, vitorlás hajóval. (Ahogyan nálunk mondják az IT osztályon: "megqrváztatnak".)

    Gondolnod kell a saját jövődre mint menedzser? Nem árt jóban lenni a nagy cégekkel (MS, Oracle stb.) hiszen csak náluk vannak olyan pozíciók, amelyekre továbbléphetsz majd egyszer.

    Stb.
    Mutasd a teljes hozzászólást!
  • Feltéve ha karbantartja azt valaki. De mi most arról a helyzetről beszélünk, amikor már nem.

    De ha az eredetit nem tartja karban senki, akkor milyen forkról és azzal kapcsolatos plusz költségről beszélsz? Egyáltalán mihez képest jelentkeznek akkor plusz költségek? A már nem létező alternatívához képest? Nincs semmi értelme annak amit mondasz.

    Ja. Nyilván, ha te forkolod mondjuk a yii-t (ha teszem azt megszűnik a támogatása), kijavítasz benne egy hibát, akkor nyilván előre látod a másik 300 hibát is ami még benne van.

    Nem erről volt szó. Hanem arról, hogy ha forkolod, akkor tudod, hogy az mivel jár. Nem pedig meglepetésszerűen ér, hogy azzal plusz meló van. Ha te mégis a fork mellett döntesz, akkor nyilván jó okod van rá: az, hogy még így is összességében jobba, olcsóbban jössz ki. Ha nem, akkor nincs értelme forkolni, tehát nem fogod megtenni, és így ezzel kapcsolatos plusz költségeid sem jelentkeznek.

    Nem mellesleg, bár neked valószínűleg rejtély az ilyen verziókezelő rendszerek működése, de azért egy idő óta már tudják ezek azt, hogy közös bázishoz (trunk/master) képest külön brancheken vezetett módosításokat automatikusan összefésülik. Tehát a központi kódtárba bevezetett 300 hibajavítás átvezetése/átvétele a saját forkodba kb. két kattintás.

    Nem. Azért dönt e mellett, mert még mindig kisebb kiadás neki ezt tenni, mint újraírni a rendszerét. De ez akkor is plusz kiadás ahhoz képest, mint ha a hibát a frameworkot fejlesztő cég maga javítaná ki.

    Ha a frameworköt a fejlesztő cég kijavítja, akkor értelmetlen a forkolás a hibajavítás céljával, nem? Akkor már megint miről beszélsz?

    A cégeket viszont vezetők irányítják. Bizony, csúnya karrierista vezetők. Ez a világ már csak ilyen.

    Örülük, hogy végre elfogadod ezt. Kár, hogy kellett megint vagy 20 hozzászólás arra, hogy egy ilyen evidens dolgot és ebből eredően azt is megértsd, hogy - korábbi állításoddal szemben - nem azért választja a bank sem a multitól származó megoldást a nyílt forráskódú helyett, mert előbbi technológiai szempontból jobb, biztonságosabb vagy mert nagyobb eséllyel fog X év múlva is létezni és fejlődni. Hanem mert az ottani vezető karrierista, és tesz arra, hogy technológiai szempontból, illetve a cégnek melyik a jobb. Őt ehelyett csak az érdekli, hogy neki személyesen, mint üzletembernek melyik a jobb - azaz, melyiknél jattol neki zsebbe a multi, és melyiknél lehet mutogatni másokra, ha valami balul sül el.
    Mutasd a teljes hozzászólást!
  • Egyrészt ez nem igaz, hiszen a javítás beküldhető az eredeti kódtárba is.

    Feltéve ha karbantartja azt valaki. De mi most arról a helyzetről beszélünk, amikor már nem.

    Ez ugye megint nem igaz. Egyrészt, mert a költség jelentkezése előre látható.

    Ja. Nyilván, ha te forkolod mondjuk a yii-t (ha teszem azt megszűnik a támogatása), kijavítasz benne egy hibát, akkor nyilván előre látod a másik 300 hibát is ami még benne van.

    Ha ugyanis egy cég a saját szakállra javítás, forkolás, kiegészítés mellett dönt, akkor azért teszi, mert úgy gondolja, úgy számolja, hogy azzal pénzt spórol (ahhoz képest, mint ha nem tenné). Nem pedig azért, mert plusz kiadást okoz neki.

    Nem. Azért dönt e mellett, mert még mindig kisebb kiadás neki ezt tenni, mint újraírni a rendszerét. De ez akkor is plusz kiadás ahhoz képest, mint ha a hibát a frameworkot fejlesztő cég maga javítaná ki. 

    Ez nem a cégnek jó, hanem a karrierista vezetőnek. A cégnek ez sokba kerül, miközben valódi garanciákat, pláne hosszú távon meg nem jelent.

    A cégeket viszont vezetők irányítják. Bizony, csúnya karrierista vezetők. Ez a világ már csak ilyen.
    Mutasd a teljes hozzászólást!
  • A cégnél ? Ne viccelj. Még windowsból is egyedit.
    Mutasd a teljes hozzászólást!
  • Ha egy MS szoftver életciklusa véget ér, azt évekkel előbb tudni lehet. Ilyenkor nincs probléma, szépen elindítják a termék kiváltására szolgáló projektet. Nem fognak halogatni - pont azért, mert egyrészt a projekt indítása lehetőség a projektben résztvevő managerek és dolgozók számára, másrészt pedig a kiváltás elindításának elmaradásának is meg lenne a felelőse, és az finoman szólva nem tenne túl jót az illetőnek.
    Mutasd a teljes hozzászólást!
  • A makroökonómia mellett van mikroökonómia is. Ha nekem nem éri meg foglalkozni a problémáddal, mert van jobb dolgom is, akkor nem foglalkozom vele. :)
    Mutasd a teljes hozzászólást!
  • Mond csak, hiszel te a piacgazdaságban, a piaci versenyben?

    Ha van kereslet, megjelenik hozzá a kínálat is 
    Mutasd a teljes hozzászólást!
  • Megteheti, de onnantól kezdve a saját forkján dolgozik, ami azt jelenti, hogy a frameworkkel kapcsolatos összes gond az ő nyakában lesz.

    Egyrészt ez nem igaz, hiszen a javítás beküldhető az eredeti kódtárba is. Másrészt meg egy zárt kódú programba ha a forrás elérhetősége nélkül írsz hozzá valami módosítást vagy kiegészítést, akkor onnantól kezdve az azzal kapcsolatos összes gond nem a te nyakadban lesz? Akkor már megint miről is beszélsz? Mitől specifikus, csak a nyílt forrású projekteket érintő probléma ez? Ha meg nem az, akkor minek írod ezt le?

     Azaz lesz egy rakás előre be nem tervezett költsége.

    Ez ugye megint nem igaz. Egyrészt, mert a költség jelentkezése előre látható. Az nem csak úgy hirtelen, mint derült égből a villámcsapás beüt, hanem annak egyenes és elkerülhetetlen következménye, hogy a cég saját maga kezébe veszi a hibás vagy hiányzó funkció javítását vagy pótlását. Ami így ezzel összefüggésben tudja és várja is ennek minden következményét.

    Másrészt itt értelmetlen plusz költségről beszélni, hanem legfeljebb plusz nyereségről lehet. Ha ugyanis egy cég a saját szakállra javítás, forkolás, kiegészítés mellett dönt, akkor azért teszi, mert úgy gondolja, úgy számolja, hogy azzal pénzt spórol (ahhoz képest, mint ha nem tenné). Nem pedig azért, mert plusz kiadást okoz neki.

    Tehát az egész - állításoddal szemben - egyrészt nem lesz váratlan számára, másrészt összességében nem költséget, hanem megtakarítást, nyereséget eredményez neki. Ezért teszi, ha teszi.

    Nekik az a jó, ha van egy szép nagy, lehetőleg patinás cég aki az infrastruktúrát szállítja, és akire mutogatni lehet ha valami nem gömbölyű.

    Ez nem a cégnek jó, hanem a karrierista vezetőnek. A cégnek ez sokba kerül, miközben valódi garanciákat, pláne hosszú távon meg nem jelent.

    Warez persze szóba sem jöhet, de trial verzió szokott lenni. De szigorúan a gyártótól.

    Tehát semmi különbség nincs a között, ahogy a nyílt forrású és a zárt forrású komponensekkel eljártok, és mindegyikkel szemben valójában ugyanazokat az elvárásokat lehet és szokás is támasztani. Ezért mondtam, hogy totál értelmetlen a felvetésed.

    A nyílt forrással az a baj, hogy ott kevésbé van garancia arra, hogy valaki nem küld be egy olyan patchet ami szándékos sebezhetőséget tartalmaz.

    Ez megint nem igaz. Legkésőbb a Snowden féle leleplezések óta tudjuk, hogy a kereskedelmi megoldásokban is ott vannak a direkt beépített sebezhetőségek, gyengeségek. Méghozzá az olyan zárt forrású megoldásokban is (sőt, leginkább azokban), amiknek kifejezetten a biztonság biztosítása lenne a célja. És amik a legnagyobb és elméletileg legmegbízhatóbb gyártóktól származnak. Innentől kezdve a fenti kijelentésed megint teljesen abszurd.

    Kereskedelmi komponenst - ha meg tudod indokolni hogy miért kell, és a management rábólint - akkor a cég megveszi és használhatod. Opensource szimplán tiltva van, bár lehet hogy eseti kivételt valahogy lehet tenni, még nem láttam rá példát.

    Ha ez így van, akkor ez nyilvánvalóan egy hülye házirend. Egyrészt, mert a kereskedelmiség és a nyílt forrás nem zárja ki egymást. Másrészt a korábban írtak miatt. Bizonyítani mindenesetre nem bizonyítja azt a vitatott állításod, ami szerint a zárt kódú megoldásokra és platformokra célszerűbb lenne és jobban lehetne építeni hosszabb távon (pl. a 20 éves távon, amit többször is emlegettél), mint a nyílt  forrású társaikra.

    Nem érted. Nem elég tisztességesnek lenni, annak is kell látszani.

    Nem érted. Attól nem hogy tisztességes nem lesz, de még csak annak sem fog látszani senki, hogy pénzért adja a szoftverét aminek a forrása sem férhető hozzá. És attól sem fog senki tisztességtelennek még csak látszani sem (és pláne nem lesz tisztességtelen), hogy a programja forrását bárki számára hozzáférhetővé teszi, és esetleg még pénzt sem kér érte közvetlenül.

    Nem attól lesz jó és megbízható egy program, hogy zárt vagy nyílt forrású -e. És a kód zártsága vagy az, hogy egy jól meghatározott cég készíti az adott kódot, nem garancia arra sem, hogy az az adott eszköz jó minőségű lesz, azt fogja tudni majd ami éppen neked kell, vagy éppen csak létezni is fog az általad emlegetett 20 (vagy akár csak 5) év múlva.

    A managert nem az érdekli, hogy mennyire biztonságos a szoftver, hanem az hogy mennyire van biztonságban a hátsója ha gond van. Ha a megoldás mögött egy SAP, egy Oracle, egy Microsoft van, akkor ha beüt a ménkű, akkor lehet mutogatni.

    Köszi, hogy megerősítetted, amit a kezdetek óta mondok. És, hogy cáfoltad a saját kijelentésed, ami szerint a manager azért döntene a kereskedelmi megoldás mellett, mert az feltétlenül jobb minőségű, kiszámíthatóbb és hosszabb távon megbízhatóbb lenne.

    Nem, nem azért dönt mellette. Hanem azért, mert - ahogy végre magad is megállapítottad - hogy védje a saját fenekét. Teljesen függetlenül az adott megoldás objektív, technikai kvalitásaitól: megbízhatóságától, minőségétől és pláne attól, hogy hosszú távon mi lesz vele. Mert azt aztán végképp' nem tudja, illetve, sokkal kevésbé tudja egy kereskedelmi entitás garantálni, mint az, hogy ha nyilvános a program kódja, amit így - legalábbis elméletileg - bárki, bármikor tovább vihet.

    Ezért örülük, hogy a végére csak elfogadtad és magadévá tetted az álláspontomat. Még ha a sok vita közben annyira össze is zavarodtál, hogy már valószínűleg kezdted azt hinni, hogy ezt te mondtad, miközben majdnem egész végig vitattad, és pont az ellenkezője mellett kardoskodtál.
    Mutasd a teljes hozzászólást!
abcd