.NET Red Hat Enterprise Linuxon - hamarosan...

AlmaLinux, CentOS, Fedora, Red Hat, Rocky Linux

.NET Red Hat Linuxon

You may have heard Microsoft ♥'s Linux. And soon you will be able to use .NET on Red Hat Enterprise Linux. While the pieces are still being finalized we are excited to share a behind-the-scenes sneak peek at how this will work for you.

- [ forrás ]

( artifex | 2016. 04. 10., v – 20:09 )

Kezd egyre izgibb lenni.

"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."

( Zahy v | 2016. 04. 10., v – 20:52 )

Flame
Kezd felértékelődni a Slackware. Nincs valahol egy up-to-date kernelt használó Yggdrasil? /Flame (Ja, és semmi bajom nincs a .NET-tel, csak nem tetszik a színe.)

( answ | 2016. 04. 10., v – 22:09 )

A Microsoft a Nokiat is megszerette.
Ki akar meg egy medveolelest?

( BehringerZoltan | 2016. 04. 10., v – 22:42 )

Most képzeljünk el egy állatkerti képet, ahol a Microsoft vezír a pingvinek etetése tilos táblát bámulja!

( b | 2016. 04. 11., h – 00:54 )

Ezt is meg a jávát is kellene felejteni.

--
GPLv3-as hozzászólás.

Köszi! A Swiftről pont nem ejtenek szót, de pl. itt van https://grigio.org/go-vs-node-vs-rust-vs-swift/ és https://www.quora.com/Will-an-open-source-Swift-be-a-strong-competitor-…. Async lib van mindkettőhöz, a C++ future-promise megoldásához képest szebbnek tűnnek.

A memória menedzsment örök téma, GC kontra RC, vagy épp Rust vs Swift témában a borrow vs. weak.

Gyengeség? Kb minthogy UNIX/Linux root shell nem kérdez rá a veszélyes parancsoknál hogy "biztos vagy benne? Tutituti? De tényleg?"
Ahhoz hogy sokkal hatékonyabban működjön valami, le kell vetkőzni sajnos azt a réteget, ami bolondbiztossá teszi. Cserébe úgy kell hozzányúlni mint egy élesített bombához = szakértő kell hozzá, a többiek instant belepusztulnak, a rosszabbak magukkal rántják a felhasználóikat is.

Akkor mondd el, hogy miért programoznak amatőr programozók is "mission-critical" rendszereket C-ben egy desktop számítógépnél. Ahol 5% teljesítménycsökkenést megér az, hogy ne legyen Heartbleed, ne legyen gotofail és társai.

Az a helyzet, hogy a szoftverszükséglet nagyobb mértékben nő, mint amilyen mértékben az oktatás szakértőket tud kinevelni. Épp ezért nincs más út, mint bevezetni a runtime védelmét.

Ugyanis ilyen erővel írjunk mindent assemblyben - az még a C-nél is hatékonyabb.

Nem mondtam, hogy sehol nem kell. Csak azt mondtam, hogy a modern szoftverek biztonsági hibáinak jelentős része C nyelvi hiányosságokból ered. És épp ezért szar nyelv a C magas biztonságú szoftverek írására. Nem véletlenül létezik a JPL/MISRA coding guildeline, ha már a nyelv buta.

Értem én, hogy a nyelv überhatékony, a legjobb, a legszuperebb, és minden más egy lomha fostenger hozzá képest, csak az a helyzet, hogy kenheted a hajadra a teljesítményt, ha éppen szoftverhiba van a programozó figyelmetlensége miatt, méghozzá olyan szoftverhiba, amit a runtime triviálisan ki tud szűrni.

"sehol sem kell/erdems C -t hasznalni tovabbra is,"

Az emberek elenyésző része kódol olyan helyre, ahova a C valóban indokolt. Beleértve a mai oprendszerek kerneleit és az összes létező desktop programot, mielőtt valaki ezzel jönne.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Mondjuk szerintem a C++ sem feltétlen legjobb nyelv, mert low-level nyelvnek túl high level, high level nyelvnek túl low level, de legalábbis nincsenek benne egzakt határok, szóval számomra amolyan két szék közül a pad alá nyelv. Hozzáteszem, C++11 és folytatásai sokat lendítettek előre a nyelven. Illetve, amit még nem szeretek benne az az, hogy bár szinte mindenre van valami megoldás, az absztrakció mögüle hiányzik sokszor. Ld. interface vs pure virtual class.

Egyébként már csak abból a szempontból is jobb nyelv szerintem, mint a C, hogy most is legtöbb esetben valójában valami objektum-szerűt próbálnak létrehozni és/vagy interfaceket deklarálni, amit szvsz már önmagában triviálisabb lenne egy OO nyelvben. Illetve, sokkal jobban védhetőek lennének az adataid is, hogy nincs egyből az egész külvilágnak feltétlen kipublikálva minden.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Mondjuk ehhez hozzátartozik az is, hogy minden elterjedt kernel és szoftverarchitektúra 40+ éves, a 70-es évek óta a WIndows NT/VMS és a Unix alapelvei sokat nem változtak, és aki változtatni akarja, azt hülyének nézik (lásd mikrokernelek, OO-kernelek), mert 'úgyseleszbelőlesemmi'.

Runtime védelme... Lássuk csak:
1. Sosem volt Java kritikus sérülékenység ugye?
2. Saját szememmel láttam amikor 60% CPU időt vitt el a garbage collector egy nem túl terhelt rendszeren. Mert "az majd megoldja". Nem. Egy profi java programozó oldotta meg.
3. Ruby. Dög lassú volt a DB hozzáférés. Megkérdeztem a fejlesztőket milyen táblaszerkezetet használnak és amiket kell indexelik-e. Nagy kérdő szemekkel néztek, majd közölték hogy fogalmuk sincs. Megmutatták a kódot, amiben kb. 3 szavas utasítás tárolta el az adatot. Valahogy.

A magas szintű programnyelvek tök jók, percek, órák alatt készül el bennük valami, amit mondjuk libek használata nélkül C/C++-ban hetekig írnál. De tapasztalatlan kézben ott is csak látszólagos az eredmény.

És hogy milyen kényelmes és egyben veszélyes is mások kódjára építeni:
http://www.sciencealert.com/how-a-programmer-almost-broke-the-internet-…

1, de, volt, viszont ha egy runtime könyvtárban javítanivaló van, akkor update után mindenkinél megjavul. Ellenben a nyelv hibáját nem fogja megoldani. Szóval kicsit almát a körtével.
2, Igen, előfordul. Ilyenkor mérni kell és tuningolni. megint almát a körtével.
3, Ennek nem tudom mi köze van a runtime-hoz, illetve a nyelvi védelemhez. Megint csak almát a körtével.

re 1)
- kivéve, amikor valaki inkompatibilis módon módosítja a runtime könyvtárat
- kivéve, amikor valaki olyasmit is felhasznál a runtime könyvtárból, amit nem kellett volna, csak szarul vagy sehogy se volt elrejtve
- kivéve amikor valaki feltételezi az eddigi működés alapján, hoghy a runtime könyvtár valamit ilyen/olyan módon old meg
- kivéve stb

Összefoglalva: ha a programozó *jól* programozik, akkor ilyenek nem történnek meg.

Látszólag sem offtopic, egy megtörtént eset száz évvel ezelőttről:

magyar számtech újságban elindul egy sorozat, a Modula-2 nevű csodanyelvet tanítja. (Gy.k. Wirth-nek a Pascal utáni nyelve, amiben aztán precizitás a végtelenségig, a Modula-2-höz képest a Pascal laza erkölcsű C-leszármazott.) Első részben a hozsanna meg a halleluja szól a nyelvről, meg arról, hogy a nyelv - és a fejlesztőkörnyezet - mennyire védi a programozót az ebben a szálban is emlegetett trehány, laza stílusból adódó hibáktól. Mellékinformációként elhangzik az, hogy aki a cikksorozat szerzője, az X cég PC-s Modula-2 fordítóját használja - nekem abban az időben Y cég Modula-2 fordítója volt elérhető. Szerencsére az a cikkben világosan és eléggé szájbarágósan szerepelt, hogy az ilyen fejlesztőkörnyezetbeli különbségek szerencsére nem okoznak problémát, mert nem lesznek olyan példák, amikben kihasználna bármi fordítóspecifikusat is.

Gondolom a bevezetőből ki lehet találni, de ha nem sikerült volna: Pontosan az első példaprogram begépelése és lefuttatása idejéig tartott a nagy lelkesedésem, mert a várt eredmény helyett a szoftver egészen mást produkált. Némi nyomozás után eléggé hamar kiderült, hogy egy egyszerű változóinicializálás maradt ki, és az ő rendszere 0-ra inicializálta azt, míg az enyém valami másra.

Szóval az nagyon szép, ha egy nyelv nyújt mindenféle védelmet, de attól még a fejlesztőnek értenie kell a rendszer, amit használ - amibe beleértendő a nyelv, és a használt eszközkészlet. És ugye nincs jobb, mint a a hiba, amikor feltételezel valamit, ami igazából csak az általad használt környezetre érvényes. Ezt pedig mindig és mindennel könnyű elfelejteni, hogy a másik esetleg nem pont ugyanolyan környezetben dolgozik, mint a fejlesztő.

Abban az esetben nem Modula-2 fordító volt az egyik, vagy a másik.
Ilyen nem fordulhat elő normális esetben.
A nyelv specifikációja, ha nem egyértelmű, és megenged fordítóspecifikus és runtime-implementációspecifikus dolgokat, méghozzá olyanokat, amely a programozó felé történő interfész és a runtime viselkedésben eltér, akkor az nem egy jó nyelv.

Engem már az felbasz, hogy pl. C-ben az int mérete gépfüggő, ezért kellett bevezetni ugyebár az inttypes.h-t. .NET CIL-ben például ilyen nincs. Ott pontosan tudod, hogy CPU-tól függetlenül egy adott adattípusod hány bites.

"A nyelv specifikációja, ha nem egyértelmű, és megenged fordítóspecifikus és runtime-implementációspecifikus dolgokat, méghozzá olyanokat, amely a programozó felé történő interfész és a runtime viselkedésben eltér, akkor az nem egy jó nyelv."

nagyon jol leirtad a C nyelvet :)

--
NetBSD - Simplicity is prerequisite for reliability

> Abban az esetben nem Modula-2 fordító volt az egyik, vagy a másik.

De. Egy hibásan működő Modula-2 fordító. Amit viszont - noha a szálban az ellenkezője szerepel - nem könnyebb kijavítani, mint az én saját kódomat. Szóval összefoglalva, baromi sokan meg akartok győzni baromi sok embert arról, hogy a programozó helyett majd a környezet végzi el az ellenőrzést. Node a környezetet is programozó állította elő, és miért hiszi mindig mindenki azt, hogy a másik programozó hibátlanul kódol, csak én vagyok kisiskolás szinten?

A felvetett problémára -- nem inicializált változó -- két megoldási javaslatom lenne:
-- szigorú nyelvdefiníció, amely ilyen eseteket kizár,
-- a fordítóprogram validálása (mint pl. ahogy az az Ada nyelvnél van), amely megoldás a konkrét fordítókat ,,nyúzza'', és deríti ki, hogy mennyire felelnek meg a nyelvdefiníciónak.

G.
============================================
"Share what you know. Learn what you don't."

"Engem már az felbasz, hogy pl. C-ben az int mérete gépfüggő, ezért kellett bevezetni ugyebár az inttypes.h-t."

Nem kéne Inteles architectúrát használni, vagy kibaszni a CPU-ból ezt a lehetőséget.
Qrvaannyát a C-nek.

-----------------------------------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years - but Yoichi is coming up :)

Nem csak inteles architektúrán, pont ez a lényeg.
Az int szabvány szerint gépfüggő. Nem, nem az X86 miatt, hanem a szabvány miatt.

ARM-nál is ez a helyzet.
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0053b/IHI0053B_arm_…

"When pointers are 32 bits, the „long‟ type is 32 bits (ILP32 model).
When pointers are 64 bits, the „long‟ type may be either 64 bits (LP64 model) or 32 bits (LLP64 model)."

"The signedness of a plain „int‟ bit-field is implementation-defined [C99 6.7.2#4]."

És ebből persze az egyértelműen következik, hogy a C nyelv szar, mert támogatja a 32 meg 64 bites long int-et.
Sőt még szarabb, mert fenntartja a lehetőséget, hogy az adott platformon úgy implementálják, ahogy a platform konformitás szempontjából hatékonyabb.
Grat.
-----------------------------------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years - but Yoichi is coming up :)

Nem az a baj, hogy támogatja, hanem az, hogy nem ugyanazt jelenti különböző architektúrákon.

ld.
System.Byte (vagy byte)
System.Int16 (vagy short)
System.Int32 (vagy int)
System.Int64 (vagy long)

És ez mindenhol 1-2-4-8 byte lesz, függetlenül attól, hogy egy mikrokontroller vagy egy 64 bites szerver CPU.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ezzel én konkrétan szívtam be még anno, mikor a régi telefonomra fejlesztettem valamit. (8 biten palettázott képeket akartam megjeleníteni, simán alul indexeltem a palettát az esetek felében.)

Nem véletlen, hogy minden normális modern nyelv tartalmaz külön char és byte adattípust. (Persze, tudom, hol volt még UTF8 meg Unicode a 70-es években.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Szvsz a programozási nyelv tervezője/készítője kiindulhat a hardver irányából, azaz a nyelvben olyan típusokat valósít meg, amelyeket az adott hardver (processzor, központi egység) minden különös ráfordítás nélkül támogat (pl. az említett C-beli 

int

). Így hatékony, a hardver sajátosságait messzemenően kihasználó kód állítható elő . Ennek a megoldásnak a használata persze -- az említett 32 bitről 64 bitre, de akár a 8 bitről 16 bitre való portolásnál is -- gondokat okozhat.

Viszont nyelvet úgy is lehet tervezni/készíteni, hogy adott típusoknál nem a reprezentációt/implementációt ,,vesszük fixre'', hanem a specifikációját írjuk elő: pl. az egész típus mondjuk 16 számjegyet tartalmazzon. Az, hogy ezt a hardver hogyan támogatja, annak kidolgozása már a hardveres oldal készítőjének vagy a hardveren futó szoftvertámogatás (operációs rendszer) és a nyelv készítőjének (implementátorának) a feladata.

Ez utóbbi megoldással viszont a különböző architektúrák közti forráskód átvitel, vagy a szoftver hosszútávú -- akár új harverre való migrálással járó -- karbantartása (maintenance) talán kevesebb gonddal oldható meg, viszont a programok végrehajtásának hatékonysága már a hardverre/oprendszerre való ,,leképezés'' hatékonyságától függ.

G.
============================================
"Share what you know. Learn what you don't."

"De tapasztalatlan kézben ott is csak látszólagos az eredmény."
Tehát a tapasztalatlan kéznek a feladata bounds checket írni mindig. Értem. Tök egyértelmű.

Minden fenti példád csak annyit mutatott meg, hogy a programozónak tudnia kell, hogy mit ír le. De attól még nem kell mindent leírnia - ami automatikus, és mechanikus, az a runtime része kell legyen.
Hiszen szerintem printf()-et és int-to-float konverziót sem szoktunk írni. Mert az a runtime része.

Az a helyzet, hogy az olyan alacsonyszintű műveleteket, mint egy tömbhozzáférés ellenőrzése, azt a runtime sokkal jobban elvégzi, mint az ember.

Ugyanis a runtime-nak egyszer kell jónak lennie, míg ha emberrel csinálod, annyi hibalehetőség van, ahányszor a műveletet el kell végezni.

Sokkal komplexebb problémákat kell ma már megoldanunk szoftverrel, mint a 60-as években. Épp ezért nem az kell, hogy lekösse a figyelmünket és az agykapacitásunkat, hogy most csináltunk egy out-of-bounds ellenőrzést vagy nem. Baromira nem ez kell, hogy az időnket lekösse.

Nem véletlenül használunk egyre magasabb szintű nyelveket, meg libraryket: valaki megírja és leteszteli egyszer, a többiek meg használják. És az olyan alacsonyszintű műveletek, mint a biztonságos tömbindexelés annyira sokszor fordulnak elő, hogy alapoknak kell lennie.

A C nagy része pedig egy hordozható assembly, így is kell rá tekinteni. Azon nyelvi elemei, amelyek meg komoly runtime-támogatást kell élvezzenek (threadek és társaik) pedig ugyanúgy nem alacsonyszintűek, és ugyanúgy nem nyersz vele semmit teljesítményben.

Mindenki hibazik, a legjobb programozok is. Reszben ez van pl. a Rust mogott: a fordito garantalja, hogy ne keruljenek olyan hibak a programba, amik utana sulyos (biztonsagi) problemakhoz vezetnek, lasd pl. buffer overflow sebezhetosegek. A C nem ad ilyesfajta garanciakat, ennek meg is van az eredmenye.

----------------------
while (!sleep) sheep++;

Persze, persze, attól még a komplexitás nő, az emberi agy kapacitása meg véges, ráadásul szellemi teljesítőképessége nagy mértékben függ külső és belső ingerektől. Aki mást mond, hazudik.

Viszont a komplexitás jó részét sokszor át lehet ruházni egy szoftverre, ami sok esetben az adott feladatot nem csak precízen, következetesen, de sokszor hatékonyabban, biztonságosabban képes elvégezni. És egyébként is, jobban szeretem, ha a gép szolgál engem és nem én végzem el a gép munkáját.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

+1000

azért ezek kemény érvek, hogy minek kell out of bounds problémákkal foglalkozni, mer az gépies, a drága emberi agyat meg a komplexebb feladatokra kéne használni, nem holmi tömbindex ellenőrözgetésre. :D:D

Csak halkan megkérdezném a "C fos mer bufferowerflow-ra ad lehetőséget" hívőket, hogy ha az aranytökű szoftverész egy kibaszott tömbindex kezelésnél képtelen odafigyelni, akkor egy komplexebb algoritmnus esetén mi garantálja hogy igen?

Mindenki úgy tekint a C-re, mint egy eredendően rossz dologra, mer' pointer aritmetika meg társai.
Mitől is sokkal jobb nekem, hogy látatlanban rábízom magam egy olyan garbage collector kódra, amelyik ugyanúgy lehet bugos, mint a sajátom?

Meg kell tanulni programozni, algoritmizálni, és odafigyelni, hogy miket írkál az ember. A döfköd döfköd majd csak jó lesz pattern nem igazán célravezető, mégha olyannyira is kímélni akarjuk a szegény programozó kobakocskáját a gondolkodástól.

-----------------------------------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years - but Yoichi is coming up :)

Ugye a C elve az, hogy vannak a *nagyon okos* programozók, akik *mindig mindenre* gondolnak. Ha megnézzük, hogy a C nyelv létrehozása óta szinte MINDEGYIK komoly, nagy,
*nagyon okos* programozók által írt programban és/vagy könyvtárban találtak buffer overflow problémát, talán levonhatjuk azt a következtetést, hogy nem biztos, hogy
egy programozási nyelvnek így kellene működnie.

"Ugye a C elve az, hogy vannak a *nagyon okos* programozók"
???

Ez most hogy is?
Véleményem szerint a nagyon okos és az alapos között gigászi különbség van.
Az előző az egy adottság, a második meg egy fejleszthető képesség.

Abból, hogy MINDEGYIK programban szinte találtak buffer overflow problémát, nem azt a következtetést kéne levonni, hogy a nyelvnek nem így vagy úgy kéne működni, hanem azt, hogy a programozó nem volt elég alapos.
Már csak azért is, mert az alaposság problémáját nem lehet nyelvi stb. egyéb eszközökkel növelni.

Ha sokmillió programozó buffer overflow hibákat vét, akkor a programozási nyelv a szar egyértelműen ugye, nem pedig a lelkes pogromozó kis kezét kell letördelni.
Amíg alapvetően nem változik a processzorok utasításkészlete, addig ez a probléma mindig is jelen lesz, merhogy ez nem a C nyelv miatt született.

De nyugodtan leledzhetünk abban a kénylemes kényszerképzetben, hogy ez a C nyelv miatt van. Esetleg egy másik nyelv használatánál fellépő tipus antipatternek miatt meg fikázzuk majd azt a nyelvet. Ahelyett, hogy belátnánk, hogy oda kéne figyelni arra, hogy milyen utasításokat irogatunk le nagy egymásutánban.
-----------------------------------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years - but Yoichi is coming up :)

Csak nagyon nem mindegy, hogy miben vagy nagyon alapos. Például a progrozási nyelv runtime-ja leveszi a válladról azt a terhet, hogy a memóriacellák típusának értelmezését megcsináld, például helyesen ad össze egy int-et egy float-tal. Régen ez is a "legyen alapos a programozó" felelősségi kör alá tartozott.

Vagy a sok goto/jmp, rengeteg problémát okozott, és jött is helyette a procedurális ill. strukturált programozás, pedig csak annyi a megoldás, hogy "legyen alapos a programozó".

Ha mindenre az a válasz, hogy "legyen alapos a programozó", akkor szoftverszinten az ötvenes években lennénk még mindig. De valahogy nálunk okosabb emberek már felismerték, hogy nem ez a megoldás - azokat a "legyen alapos" dolgokat, amiket automatizálni lehet, automatizáljunk.

"Ha mindenre az a válasz, hogy "legyen alapos a programozó", akkor szoftverszinten az ötvenes években lennénk még mindig"

Mert miért is?

"Vagy a sok goto/jmp, rengeteg problémát okozott, és jött is helyette a procedurális ill. strukturált programozás"
És mondjuk a C nyelv e tekintetben mennyiben is idejétmúlt?

Meg ez az amit lehet automatizálni, azt automatizáljuk dolog sem vlágos egészen, hogy hogy jön ide?
Mi az, hogy nem megoldás az, hogy legyen alaposabb a programozó?
Majd egy (előzőleg (nem) alapos programozó által megírt) automtikus program az biztos nem fog hibázni, de legalábbis kiküszöböli a nem alapos programozói hibákat.

??? :D:D
-----------------------------------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years - but Yoichi is coming up :)

"Mert miért is?"

Mert minek fordító, hisz gépi kódot is le lehet írni.

"És mondjuk a C nyelv e tekintetben mennyiben is idejétmúlt?"

Hogy egyre inkább továbblépünk a deklaratív megoldások felé.

"Mi az, hogy nem megoldás az, hogy legyen alaposabb a programozó?"

Mert ember. Idővel fárad, elkalandozik és hibázik. Kiváltképp repetitív, ismétlődő feladatokban mérhető ez jól.

"Majd egy (előzőleg (nem) alapos programozó által megírt) automtikus program az biztos nem fog hibázni, de legalábbis kiküszöböli a nem alapos programozói hibákat."

Nyilván nem lesz az sem hibátlan, de mit az egyszerűbb javítani? Egymillió ellenőrzést átnézni vagy javítani egy fordítót, ami megcsinálja helyetted?

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"Egymillió ellenőrzést átnézni vagy javítani egy fordítót, ami megcsinálja helyetted?"

Most ezzel ugye nem azt akartad kérdezni, hogy egyszerűbb-e 1 millió kézi ellenőrzést végezni egy qrva index helyes ellenőrzése helyett?
Mert btw, a két eset ilyen szempontból teljesen egyenértékű.
Legalább annyi meló megfixálni egy compilert mint a saját kódodat.
A különbség csupán annyi, hogy a saját kódodat ismered, a compilerét meg vagy nem is tudod megnézni, vagy ha igen, akkor sportosabb megtalálni a hibás programrészletet, de fixálni kb ugyanaz.

Ha helyettem szarul csinál valamit a fordító, akkor no chance. Egyedül workaround-ot tudsz csinálni, már ha gyakorlatias oldalról közelítünk.
-----------------------------------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years - but Yoichi is coming up :)

"értem, tehát te is gépi kódban programozol, így már minden világos... "
Hát igen, ez logikus következtetés. Hogy sikerült erre a következtetésre jutni? Ezt dobta a logikai elemző framework?
(Egyébként meg igen is meg nem is. Programoztam gépi kódban, többféle assembly-ben, basic-ben, Pascal-ban, C, C++-ban, JAVA-ban, C#-ban, JavaScript-ben, shell scriptben meg egy pár egyéb script nyelvben).

"Az a baj, hogy egyik oldalról azzal érvelsz, hogy minek a fordító, a másik oldalról meg te is pont ugyanúgy fordítót használsz, mint mindenki más..."
Hát nem azzal érveltem, hogy minek a fordító. Arra próbálok rávilágítani, hogy egy nyelv eszköztárának a nem megfelelő használata nem a nyelvet minősíti, hanem az abban kódot író delikvens munkáját.

Tömören: hiába egy halom automatizmus, ami a tipushibák 90%-át kiszűr(het)i, az alaposságot nem fogja helyettesíteni.
Vakon megbízni egy eszközben, frameworkben, libraryban vagy API-ban ugyan olyan marhaság, mint kijelenteni, hogy csak a saját kódunk jó.
Nem, a saját kódunkban is lehet hiba. Ebből persze ne tessen rögvest a másik oldalra hullani, hogy "akkor találjuk fel újból a kereket, meg mindenki programozzon gépi kódban, szarjunk minden eddig kifejlesztett algoritmus implementációra, csináljunk mindenből sajátot mer az a tuti"

Csak ismételni tudom: Attól hogy x.y. eqrt egy tömbindex ellenőrzést C-ben, az nem a C hibája, hanem azé a trehány/figyelmetlen/balfasz/fáradt/qrvafaszakódercsakmosthibázottegyet/atomframeworkhözszokottésnemgondoltahogyitterrefigyelnikell/mérengedieztaCé stb. programíróé, aki azt a kódot megírta.
-----------------------------------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years - but Yoichi is coming up :)

"Tömören: hiába egy halom automatizmus, ami a tipushibák 90%-át kiszűr(het)i, az alaposságot nem fogja helyettesíteni."

Amugy pont ezert raktak bele a Java 8-ba az Optional-t. Nyilvan lehet nullchecket vegezni egy objektum lancon (Demetert most hagyjuk), de allandoan leellenorizni, hogy egy fuggveny null-safe-e, meg ilyenek, brutal sok idot elvisz am. Ezt meg frankon megoldja az Optional, mar a fuggveny szignaturajan is latszik, hogy nyugodtan lehet chain-elni, nem lesz nyul-pointer. Egyreszt olvashatobb is lesz a kod, masreszt levesz egy csomo terhet az ember vallarol.

Ugyan nem nyelv specifikus, de pl. a Design by Contract is hasonlorol szol. Az interface pontosan deklaralja hogy mire valo, milyen bemenetet var, arra milyen kimenetet ad, stb. Utana nekem nem kell turkalnom az o kodjaban, hiszen minden szukseges informacio ott van a (Java)Doc-ban. Ez is arra szolgal, hogy masok kodjanak turkalasa, ertelmezese es validalasa helyett a megoldando problemara tudj koncentralni. Ahol ezt nem tartjak be, az hamarost LegacyLand-en talalja magat kodugyileg.

Szerk:

"Vakon megbízni egy eszközben, frameworkben, libraryban vagy API-ban ugyan olyan marhaság, mint kijelenteni, hogy csak a saját kódunk jó."

Marpedig pont errol szol a webfejlesztes nagy resze. Nyilvan nem vakon bizik meg az ember az API-kban, librarykban es egyebekben, hanem utana olvas, hogy milyen ismert bugok vannak, stb. Ez nagy ceges kornyezetben meg ugy nez ki, hogy az arra hivatottak ezt szepen elintezik, szoval az atlag Joskanak meg ezzel se kell foglalkoznia.

> Marpedig pont errol szol a webfejlesztes nagy resze.

Így már értem, miért tart ott a világ, ahol.

> hanem utana olvas, hogy milyen ismert bugok vannak, stb. Ez nagy ceges kornyezetben meg ugy nez ki, hogy az arra hivatottak ezt szepen elintezik, szoval az atlag Joskanak meg ezzel se kell foglalkoznia.

Ez szépen hangzik, de kétlem, hogy igaz lenne, nagy céges, versenyszférás tapasztalatokat nézve...

Jaaaa, igy mar ertheto, es ne is emlitsd :D

Epp ezert gondolkozok azon is, hogy web-rol (de legalabbis a frontendebb reszerol) valtani kene valami masra. Viszont nem tudom hosszabb tavon mi erdekelne, meg mire eleg a tudasom. Gondolkoztam mikrokontrollereken, de elektronikahoz annyira nem konyitok, es bar tanulhato, de az, hogy elbohockodok egy Arduinoval nulla felelosseg mellett, az megint mas. Debugolni sincs fogalmam se hogy lehet ezeket hatekonyan, vagy ugy egyaltalan. Azzal meg en lehet agyfaszt kapnek.

3D/VR lehet tetszene, kerdes ott is, hogy mennyi az erdekes programozas es mennyi a kulimunka. Valami interaktiv VR startup vagy valami, az nem lenne rossz, viszont ok nagyon nem juniorokat keresnek.

Gepeszeti meg komolyabb dolgokban nem is gondolkozom, nincs meg hozza a matekom.

Valszleg marad az, hogy megprobalok kicsit backendebb fele mozdulni, ugyis van meg mit tanulnom parhuzamositas, deployment es hasonlok teren.

Embedded fejlesztéshez nem feltétlen kell elektronika, egy szoftveres általában kézhez kapja az eszközt, amire fejleszt.

Debugger persze változatos: van, ahol nincs, van, ahol van. Sokszor nincs meg az a kényelem, hogy leraksz egy töréspontot, meg figyeled a változókat, meg stack trace - mert pl. hardver nem támogatja, a debugger hardver túl drága, kinn van a prérin, stb.
Magam részéről mit tanultam ebből: kódmegértés sokkal jobban megy, alternatív debug módszerek megismerése, sok ilyen. Gondolkodtam már azon, hogy egy igen jó tantárgyat/labort lehetne összerakni csak abból, hogy debugolunk.

Előnyei: megtanulsz gondolkodni programozás közben (sokszor nagyon át kell gondolni, mit csinálsz), sokkal több az érdekes kihívás (nincs az, hogy "majd rakunk alá nagyobb hardvert"), fizikailag kézben foghatod az eszközt, amit elkészítesz, nem az n+1-ik webshopot kell megírnod.

Annak, aki le mer jönni a kényelmes absztrakt világból, aki kellő alázattal tudja a korlátokat kezelni, annak nagy kaland.

+1
Az Optional semmit nem old meg, sőt. (najó, a flatMap szép)

Kellett volna nyelvi szinten az a nullable típusosság, mint ami Kotlinban van. Vagy amiről saxus linkelt ide egyszer egy githubos linket, hogy a C#-ba javasolta valaki.

Röviden: 



Integer i = 0; // sosem lehet null
Integer? i = 0; // lehet null

public void tst(Integer i); //nem hívható nullal, vagy Integer? típussal, csak null-check után

Vagy, hogy a visszafele kompatibilitást ne törjük el, akkor a not null típusokat vezették volna be. (ez csak egy röpke gondolat, de nem lenne megoldható?)
--
blogom

őszinte leszek, most nem értelek.

én pont azért sírok, mert nem került be nyelvi szinten (fordítási időben ellenőrizve), hogy olyan függvényt, ami szigorúan nemnull paraméterrel hívnék, csak fordítási időben beláthatóan nem null paraméterrel hívhassak.

nem a programozótól várom el, hogy észnél legyen - a fordítótól várnám el, hogy ezt is figyelje, kiszűrje.
--
blogom

"Vagy amiről saxus linkelt ide egyszer egy githubos linket, hogy a C#-ba javasolta valaki."

Konnyen lehet hogy ezt linkelte: Proposal for non-nullable references (and safe nullable references).
Backlog, Planning, Ready, Working, In Review labelek kozul a Working (dolgoznak rajta) van hozzarendelve.

jupp, ezvoltaz.
A Kotlinban valami ilyesmi lett, csak ott kétfajta referencia van: nullable (kérdőjellel jelölt), s mandatory (nincs jelzés).
A Java-ba is a proposalban vázolt módon kerülhetne be, hogy a visszafele kompatibilitást ne törje el.
Ha a C#-ba bekerül, kurva irigy leszek rájuk.

(egyre inkább fontolom, hogy meg kéne vizsgálni a .NET-et mélyebben - így, hogy nyitottak Linuxra egy csomó mindent. meg egyre inkább várom, hogy végre valaki elforkolja a Javat az Oracle alól, ahogy _Franko_ emlegeti itt...)
--
blogom

Megtalaltam vegre a listat is hogy mit terveznek a 7-esbe: C# 7 Work List of Features

Nekem itt is tetszik az uj irany amit az MS vett. Kar hogy nincs idom/lehetosegem az ujabb dolgokat (CoreCLR, Roslyn, stb.) alaposabban megnezni, kiprobalni. Es akar olyan uj dolgokat is mint a stackalloc operator referencia tipusokra.

Az a gond, hogy ezt C#-ban már az alapjainál elkúrták, mert ez az int? ez valójában a Nullable<T> (ami a .NET 2-ben a genericsszel jött be). És csak struct-okra működik, és igazából arra találták ki, hogy az egyébként érték típusoknak tudjál null-t adni.

Az igazi az lenne, ha alapból a referencia típusok is non-nullablek lennének, kivéve, ha explicit megmondod, hogy az lehet null is.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

na ja, ezzel nem is itt van gond.

hanem ha van egy 

public void foo(Option<Bar> bar);

függvényem, akkor ki garantálja, hogy Józsika nem hívja meg null paraméterrel? Miért nem lehet ez compile time check?

Vagy a Józsikától kapott Option-t még csomagoljam be egy Optionbe, és akkor az 

Option<Option<Bar>>

-ból mapeljek oda, ahova akarok? /irony

Javaslom átnézésre a Kotlinos megvalósítást: https://kotlinlang.org/docs/reference/null-safety.html
By default, compile time check, nullable típuson nem hívhatsz semmit. 

?.

operátorral a függvényhívás olyan, mint a videóban vázolt map.
--
blogom

Paraméterben Option-t átadni eleve valami nagyon rossz tervezésre utal. Pl. miért nem lehet overloadolni a metódust egyszer nulla, egyszer pedig egy paraméterrel? Vagy esetleg olyan típusú objektumot adsz át, aminek egy metódusa Option-t ad vissza, és a függvényed meghívja az adott metódust az átadott paraméteren? Aztán lehet ennek a típusnak olyan megvalósítása, ami ad vissza valamit, meg olyan, ami nem.

Láttam már a Kotlin megoldását, meg azt is tudom, hogy a nyelvet a Scala inspirálta, meg azt is, hogy pont el akarták kerülni az Option használatát. :) Valóban van hasonlóság a két megoldás között, viszont az Option okosabb, mert egyben használható, mint 0 vagy 1 elemű collection, ami sokszor elég hasznos tud lenni, míg ezzel a megoldással néhány dolgot (szerintem) nem tudsz szépen megoldani, pl.: 


val a: Option[Int]
a.contains(42) // a == Some(42)
a.exists(_ == 42) // mint a contains, Scala 2.10-ben még nem volt Option.contains
a.forall(_ == 42) // a == None || a == Some(42)

val b: Int?
a == 42 // mint fent a contains vagy az exists
a == null || a == 42 // mint fent a forall
a ?: 42 == 42 // szintén forall, szerintem ronda hack a nullcheck elkerülésére
// egyéb megoldás?

Igaz, arra tényleg nincs garancia Scalaban, hogy egy referencia ne lehessen null, de a gyakorlati tapasztalatom azt mutatja, hogy lehet olyan kódot írni, amiben egy referencia soha sem lesz null. Mi ezt megtámogatjuk statikus kódellenőrzéssel (a build failel ha null-t talál a kódban), illetve nem használunk olyan libraryket, amik nullt adnának vissza.

> Paraméterben Option-t átadni eleve valami nagyon rossz tervezésre utal. Pl. miért nem lehet overloadolni a metódust egyszer nulla, egyszer pedig egy paraméterrel?
jajj, nem, félreértettél (szarul fogalmaztam, bocs). Erre akartam reagálni: „de allandoan leellenorizni, hogy egy fuggveny null-safe-e, meg ilyenek, brutal sok idot elvisz am”. A függvény null-safe-ségét pont nem oldja meg az Optional.

van egy ilyen metódusom: 


public void isAdult(Integer age) {
    return age > 18;
}

no, itt semmi nem garantálja, hogy Pistike nem hívja meg ezt így: 

isAdult(null)

. Akár szándékosan (mert hülye), akár véletlenül (a frontend framework kitöltetlen kor esetén olyan null-t ír egy változóba, ahogy kell, pl). Ebből az lesz, hogy én az isAdultban is ellenőrizni fogok nullra (s ha null, akkor tökön lövöm magam) - s jobb esetben Pistike is, a hívó oldalon, mert neki meg a frontendre ki kéne rakni, hogy Hé, haver, töltsd már ki a korodat!. (nyilván, dokumentáljam le. attól még, ha bármelyikőnk figyelmetlen, ez előjön - miért nem ellenőrizzük fordítási időben?)

Erre az Optional használata sem megoldás, mert ha 

public void isAdult(Optional<Integer> age)

van (s én lekezelem, ha az Optionalben nincs érték), akkor sem tiltja semmi, hogy Pistike nullal hívja.

> míg ezzel a megoldással néhány dolgot (szerintem) nem tudsz szépen megoldani
Sajnos se a Scala-t, se a Kotlint nem ismerem (legfeljebb Hello world szinten). A Kotlint szeretném - néhány hónap múlva megpróbálom megemészteni ezt a bekezdést.

> de a gyakorlati tapasztalatom azt mutatja, hogy lehet olyan kódot írni, amiben egy referencia soha sem lesz null
hogyan oldotok meg, mondjuk DB-műveleteket?
login, például? User beírja a felhasználónevét, jelszavát. Megkeresem DB-ben az adott felhasználónevű usert, ... Itt nálam mindenféleképpen játszik egy null. (Tényleg érdekel, elképzelni nem tudom, hogyan másképp. Vagy már ORM szinten is Exceptiont vársz el, ha nincs result?)

> illetve nem használunk olyan libraryket, amik nullt adnának vissza
Ezzel az a gondom, hogy itt csak a dokumentációra támaszkodhatsz. Egy adott verzió-váltásnál megint mindent végigböngészel, hogy a Bar library Foo metódusa nem-e adhat vissza mostmár nullt is? Azért egy kicsit-is-nagyobb kódbázisnál ez borzasztó meló - mikor a compiler meg tudná csinálni.
--
blogom

Miért nem lehet azt mondani, hogy az isAdult-ot nem lehet nullal meghívni, és boldogan elszállunk egy NPE-vel ha mégis? Mivel a függvény nem tudja eldönteni, hogy null esetén mi lenne a helyes válasz, ezért nagyon mást nem tehetsz, egy IllegalArgumentException sem jobb, mert az alapprobléma az, hogy egy exceptionnel mellékhatást okozol. De igazad van, tényleg jobb lenne, ha már a fordító megfogná ezt az esetet, és nem engedné nullable típussal meghívni a függvényt. De mi van akkor, ha azt mondom, hogy ahol bejön a user input, ott nem engedsz null-t tovább, és ezt nem neked kell megírnod, hanem kapsz library támogatást? Tulajdonképpen ugyanazt kell csinálni, mint a másik oldalon, a DB-vel való kommunikáció esetén.

DB elérésre ScalikeJDBC-t használunk, ez pl. single vagy first result esetén eleve Optiont ad. Paraméternek átadott Optiont automatikusan kezeli, és ha egy adott mező nullable, akkor ki lehet szedni az értékét Optionként (Opt suffix). Ha egy értéket nem optionalként szeretnénk megkapni, de az null, azt a library exceptionnel honorálja.

> Miért nem lehet azt mondani, hogy az isAdult-ot nem lehet nullal meghívni, és boldogan elszállunk egy NPE-vel ha mégis?
persze, lehet - csak ez kicsit olyan, mint lejjebb a C-s buffer overflow VS. managed kód vita. részben hitbeli (ki mit szeret), elismerem.

A többire köszönöm, megjegyeztem.
--
blogom

Megváltoztak a folyamatok is:
* sokkal nagyobbak a kódbázisok, mint 20-30 éve
* mások a módszertanok
* gyorsabban válzoznak a piaci igények is.

Én sem hiszem, hogy a C (vagy akár a C++) ma a legköltséghatékonyabb választás lenne egy feladat megoldására (már amennyiben megoldható a feladat egy managelt technológiával).

Fuszenecker Róbert

'hanem a rendszeré', hat igen nem a programozo volt nagyon hulye. ;-)

'hogy egy tömb indexelés nincs védve, az viszont a C nyelv hibája.'
Ilyet akkor mondhatnak,
ha egyetemesen elfogadott teny lenne, hogy pl. a boundary check szukseges MUNDEN egyes hozzaferesnel.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"Ilyet akkor mondhatnak,
ha egyetemesen elfogadott teny lenne, hogy pl. a boundary check szukseges MUNDEN egyes hozzaferesnel."

Bármilyen fontos szoftvernél, ahol feltétel, hogy ne fossa össze magát, és ne legyen benne lehetőség sem a buffer overflow hibákra, igen, ez egyetemesen elfogadott tény.

https://www.owasp.org/images/0/08/OWASP_SCP_Quick_Reference_Guide_v2.pdf
Alap a validate data range, validate data length.

De hát tudjuk, sokan szeretnek insecure-by-default kódot írni.

Amint egy függvényedet más is meghívhatja, az bizony publikus lesz. Sok hiba pont abból ered, hogy hopp, publikussá teszünk egy internal API-t, de mivel internal volt, basztunk az input validationre, hiszen senki más nem hívja a kódot, csak mi.

Aztán lett belőle szép sechole.

A https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing mintájára lehetne "Fallacies of library programming" guide-ot is csinálni.

És a biztonságos szoftver igenis mindent mindenütt checkel, ahol control transfer van.

Az SQL injection nem az SQL nyelvi runtime hiányossága.
Hanem azé, aki SQL stringeket pakol össze.
És pont ezért születtek meg azok a keretrendszerek, amelyek az SQL sztringek mechanikus összerakását (mert totál mechanikus a dolog) a programozóróla gépre helyezi át. Mert a gép kevesebbszer vét mechanikus hibát, mint az ember.

"Meg kell tanulni programozni, algoritmizálni, és odafigyelni, hogy miket írkál az ember. A döfköd döfköd majd csak jó lesz pattern nem igazán célravezető, mégha olyannyira is kímélni akarjuk a szegény programozó kobakocskáját a gondolkodástól."

Tehát nyilván az összes nagy, opensource manyeyeballs C kódban lévő buffer overflow az csak úgy magától belekerült a kódba, a tökéletes open source programozók nem tehetnek róla.

A buffer overflowra figyelés nem gondolkodás, ponthogy totál mechanikus dolog. Gondolkodás az, amikor megírsz egy hatékony elosztott hálózati kódot. Ott baromira nem azok a problémáid vannak, hogy "az x buffert ha i-vel indexelem, túlírom-e".
Olyan ez, mint valaki azt is gondolkodásnak nevezi, ha bemagolja töriből az évszámokat, meg kémiából a vegyületek tulajdonságait. Ez baromira nem gondolkodás. Csupa mechanikus dolog, amiben a gépek sokkal jobbak, mint mi.

+1

btw, eszem megáll, hogy egy qrva tömbindex kontrollból, mi a fenéért deriválódik az, hogy a nyelv a szar mer hagyja, hogy túlindexeljünk ... megalol

Majd a keretrendszer az faszán csekkolja eztmegazt. Aha igen. Mintha nem qrvára mindegy lenne az, hogy egy szutyok többszörösen ágyazott ciklusban arra nem figyel a delikvens, hogy a tömbindex változó ne szálljon el, vagy akármilyen másik iterációs lépést tartalmazó változó.

Ha valaki ennyire meg van győződve arról, hogy a C hibája ez, akkor használjon másik nyelvet.
használjon mondjuk C++-t, implementáljon egy saját index operátort, amelyik rábasz a kezére, ha túl akar indexelni és probléma megoldva.
De hogy miért a C hibája az, hogy egy programozó trehány köcsög volt, azt máig nem veszi be az agyam.

Kb ne használjunk rm parancsot, mert ki lehet adni a "rm -f /" parancsot is vele.

:D:D:D
-----------------------------------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years - but Yoichi is coming up :)

Meg normális disztrókon a géppuska kezű ökör adminok kiküszöbölésére aliasolva van az rm parancs 'rm -i'-re, hogy mégeygszer rákérdezzen reszelés előtt. ... :)
-----------------------------------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years - but Yoichi is coming up :)

Tehát a normális admin a környezetét úgy állítja be, hogy az végezzen plusz munkát, és védje meg tőle. Na és mi van, ha az rm implementációja hibás? :)

Pedig mindent megold az, hogy legyen alapos az admin. Teljesen felesles a -i használata, csak visszafogja a törlés sebességét. Le vele! :)

`btw, eszem megáll, hogy egy qrva tömbindex kontrollból, mi a fenéért deriválódik az, hogy a nyelv a szar mer hagyja, hogy túlindexeljünk ... megalol`

Mert, ha csek telifossa a logot valami exceptionnal, akkor az jo kod ;-)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Akkor nézd már meg, hogy mi történik, hogy ha túlindexelsz egy c-ben írt kódban egy tömböt (esélyes tetszőleges parancs végrehajtása egy megfelelő inputtal) vs
ugyanez történik tetszőleges javascript, java, php, python, etc. nyelvekben: kap egy exception-t a logba, és ennyi.

+1

volt szerencsém nekem is látni olyan J2EE applikációt, ami szerette (nem normál működés során) tolni a logokat,
úgy 7-8GB/24h sebességgel. :D
-----------------------------------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years - but Yoichi is coming up :)

Ha az üzemszerű működésnél tervezett, ügyfél által kért log mennyiségét 10-100-szorosan meghaladó "logot" termel, akkor bizony jogos az anyázás, pláne, ha az a "log" gyakorlatilag szemét - a szerencsés utolsó/első 1234 soron kívül, amiben látni lehet, hogy hol/miért f0sta össze magát a kód...

Legalabb van egy kis nyomasgyakorlas hogy minel hamarabb javitsak a hibat. :)

Jo esetben egy stacktrace nagyban tud segiteni a hibajavitasban. Ha meg meg plusz adatok is vannak melle logolva, az mar maga tud lenni a mennyorszag.
Volt szerencsem olyan bugot keresni ami c-s kodban tomb tuliras volt. Mindig mas helyen szallt el, es olyan helyeken ahol egyebkent nem lett volna szabad. Eleg sok szalat hasznalt a progi, igy legtobbszor meg ez sem egyezett a hiba helyevel. Szerencsere azert elmondhatom hogy nem az en kodom volt. :)

Kivancsi lennek kinek milyen a legrosszabb hibahoz fuzodo elmenye.

A várható normál terhelésből indulnék ki - hogy a karácsony előtti időszakot tervezetten további erőforrások bevonásával, vagy bizonyos folyamatok átszervezésével/elhagyásával lehet megoldani, az a terhelésnövekedés várható nagyságától függ. (Volt ilyenhez szerencsém, év közben kényelmesen dolgozott a motyó, a karácsonyi roham idején azért erősen csúcsra lett járatva, de kellően rugalmas és terhelhető rendszert raktak össze a kollégák)

Itt kifejezetten a nem üzemszerű működés miatt nagyságrendjében megnövekedett logmennyiségről volt szó. Egy webshop esetében a karácsonyi forgalomnövekedés üzemszerű állapot :-P

"Egyébként nem tudom feltűnt-e, a világ egy jelentős része túllépett a for-on"
Egyébként nem tudom feltűnt-e, hogy nem csak for esetében tud az ember nem odafigyelni változók megfelelő értekadására/nem adására.
Iterátoroknál is simán szophatsz a csudajó kóddal bizonyos esetekben.

Mondjuk egy alacsonyszintű byte sorozat másolásnál alaul valószínület valaki valamilyen for vagy while ciklust használ.
Ha nem is az istenadta programozó, hanem a tutira megírt framework ...
-----------------------------------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years - but Yoichi is coming up :)

"Iterátoroknál is simán szophatsz a csudajó kóddal bizonyos esetekben."

Pl? De akkor vegyük számba, hol szívhatsz többet.

"Mondjuk egy alacsonyszintű byte sorozat másolásnál alaul valószínület valaki valamilyen for vagy while ciklust használ."

Mondjuk egy tisztességes magas szintű szoftver ott kezdődik, hogy nem dobálózik az ember random byte sorozattal, persze nyilván nem tudod mindig kikerülni, de azért csak praktikusabb keríteni neki valami típust előbb-utóbb.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"Mondjuk egy tisztességes magas szintű szoftver ott kezdődik, hogy nem dobálózik az ember random byte sorozattal, persze nyilván nem tudod mindig kikerülni, de azért csak praktikusabb keríteni neki valami típust előbb-utóbb."

Most komolyan, a magas szintű szoftverekben a tipusosság megvalósításaként az értekek másolgatása során ki kezelgeti a valós byte-hosszt és a soksok ilyen ojjektum másolásakor ki figyel az indexek nem elbaszására? Csak nem az implemetációt előtted megíró programozó?
Az biztos istenkirály kódot írt, tehát nekünk ezzel nem kell foglalkozni.
És tényleg, ha jól negírta, akkor nem is kell. (Ha jól megírta).
-----------------------------------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years - but Yoichi is coming up :)

Na igen, de melyik a valószínűbb? Hogy én 100 helyen 100x jól írom meg, vagy azon az egy helyen, ahol a keretrendszer/fordítóprogram implementálja, ott helyesen van megírva? Illetve melyik hiba derül ki hamarabb, amelyik egy pár száz felhasználó által használt rendszerben bújik meg és a mellettem ülő kolléga review-zta kajakómásan, mielőtt kiment volna élesbe, vagy amelyiket nagyon sok szoftver használja, mindegyikben másodpercenként nagyon sokszor hívódik meg és már nagyon sok fejlesztő kipróbálta/tapasztalta, hogy tényleg úgy viselkedik, ahogyan a dokumentációban le van írva.

Hogy értsd: ha a C olyan kurva jó nyelv lenne, akkor nem C-only security issuek kerültek volna elő, amik minden kódban voltak.

És hát a manyeyeballs az meg minden security problémát megold, nem igaz?

Azaz open source kódban, ami C, eleve nem is lehetne security hiba, igaz? Hiszen a C az jó, a manyeyeballs-szal együtt még jobb.

Ennek ellenére érdekes módon, minden nagy publikuc hiba C-only volt.

Te most komolyan ezt gondolod, vagy csak szivatsz?

"Hogy értsd: ha a C olyan kurva jó nyelv lenne, akkor nem C-only security issuek kerültek volna elő, amik minden kódban voltak."
Megfordítom: Ha másik nyelv olyan qrva jó lenne, hogy rendszerszintű rutinokat írjanak benne, ahol minimálisan játszik az is, hogy hatékony legyen a kód, akkor más ilyen "nyelvek számlájára írható" security issue-k is lennének.

Mivel azonban egyelőre a C/C++-nál sokkal hatékonyabb (gyors és/vagy termelékenyebb) nyelvet nemigen sikerül felmutatni, ezért de facto, hogy minden programozási hiba
innen fogva a C/C++ nyelvű programokban elkövetett hiba jó eséllyel, mivel nem tud más lenni.

A manyeyeballs-nak meg qrvára semmi köze ahhoz, hogy a C az jó vagy sem. Max lazán kapcsolódik, hogy ha egy forráskódot potenciálisan több emberke néz át, nagyobb az esélye, hogy egy nem triviális hiba valakinek szemet szúr. Ettől ez még természetesen nem gyógyír a trehány programozók ellen, ahogyan a csillámfaszlámás pluginelehető mindenrefigyelek csingilingis fejlesztői környezetek sem.

"Ennek ellenére érdekes módon, minden nagy publikuc hiba C-only volt."
Hát igen, ha 100% forráskódból 98% C, akkor annak valószínűsége, hogy egy issue C-s forrásban van-e, kb 98% ez igaz.
Btw, egy full mondjuk Oracle PL/SQL-ben írott rendszerben az issue-k 100% SQL-es hiba. Akkor most a PL/SQL de facto szar?
-----------------------------------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years - but Yoichi is coming up :)

A különbség abban van, hogy a két megközelítés közül melyik fail-fast. A C-s megoldás nem az, mert boldogan tovább fut hibásan olvasott adatokkal / korrumpált memóriával, és könnyen lehet, hogy az teljesen máshol okoz majd csak valamilyen, adott esetben egy crash-nél sokkal súlyosabb hibát.

Mit értünk hatékonyság alatt. Működő program létrehozása N/50 idő alatt? Ez a fejlesztési hatékonyság. Egy új feature hozzáadása mennyi idő? Ez bővítési hatékonyság. Elszálló program esetén a hiba lokalizáció egy stack traceből megállapítható vs debug fordított kódot kell küldeni a customernek, hogy legyen használható core file? Ez a hibajavítás hatékonysága. Teljesítményben elég gyors? Ebben az esetben ha valamit lassúnak érzünk, akkor szépen elő kell venni a profiler-t, MÉRNI!, és ami lassú, azt felturbózni (akár algoritmus váltással).

Olvasd el amire válaszoltam. Ott az algoritmus hatékonyságáról volt szó. Ha az algoritmusod O(n) és felhasznál valahol a nyelv vagy a lib-ek implementálásában egy runtime O(n^2) ellenőrzést hogy nem-e lépted túl a buffer méretét, akkor kenheted a hajadra a hiperszuper algoritmusodat, a végeredmény O(n^2) lesz ami webscale felhasználásra használhatatlan. És amikor írod, fogalmad sem lesz róla hogy a felhasznált funkciók komplexitása mi, kivéve ha tapasztalt vagy, ezzel meg visszakanyarodtunk az elejére, hogy a jó kód jó programozótól származik, függetlenül a programnyelv vagy a fejlesztői környezet kényelmi funkcióinak szintjétől.

" ami webscale felhasználásra használhatatlan. "

Mindne startup webscale és Google-scale infrastruktúrát akar, miközben 100 userük sincs :D Olyan szép ezt látni :D

Előbb működjön egy eladható szoftver. Ha jó az absztrakciós réteged, akkor bármikor cserélhetsz O(n^2)-t O(n log n)-re.

Na most itt jön be az, hogy mit akarsz csinálni. Ha most egy gyűjteményen akarsz végigiterálni, akkor arra egy picit fejlettebb nyelveken ott van az iterator, amit bevágsz egy foreach-ba, aztán mindegy, hogy tömb, lista, láncolt lista, fa, kutyafüle vagy birkavese.

Viszont ha egyszer meg van írva jól a *Iterator az adott feladatra jól, akkor lehet azt használni mindig. És breaking news: a keretrendszerek is elég sok optimalizációt tartalmaznak a felszín alatt. Jó példa erre a LinQ, ami bizony néhol sebességoptimalizáció miatt telibe szarja az OOP alapelveket - szigorúan a felszín alatt.

Különbség az, hogy nem tudod elrontani, szemben a drágalátos C-ddel.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"Honnan tudod hogy hatékony a kódod, ha nem tudod hogy mi a komplexitása (tudod a nagy O betűs) a felhasznált keretrendszernek/libeknek, stb.?"

Először is don't argue, benchmark.

Másrészt a nagy-O jelölés haszontalan sok esetben. Ugyanis sok műveletet, ami valójában nem elemi, eleminek feltételez. Úgy persze könnyű azt mondani, hogy az algoritmusom n^-es bonyolultságú. Miközben nem az, mert maga az algoritmus által felhasznált "elemi" lépés baromira nem elemi.

Harmadrészt: a való életben (és minden mérnöknek) a lényeg, hogy egy művelet mondjuk 95%-ban befejeződjön 150msec-en belül. És nem érdekes ilyenkor, hogy n^3 vagy n^2-es algoritmussal, vagy n lg n-essel írod meg, mert az input mérete amúgy konstans és a szoftver teljesíti a követelményeket. Senki nem fogja neked kifizetni azt a melót, hogy kielemezd a futásidőt, ha amúgy a futásidő nem probléma.

Nagyon szeretem, amikor a C kóderek azt állítják, mintha minden kód a világon hard-realtime, 2 kb memórián és egy 4 kilohertzes CPU-val kéne, hogy lefusson. Na, ezek az emberek még nem láttak business kódot, ahol a lényeg mondjuk 45 alrendszer és 25 vendor szoftvereinek az integrálása. Na, ott baromira nem az lesz a lényeg, hogy a keretrendszernek mi a lefutása.

Amúgy te a napi munkád során dokumentálod-e a futásidőt O, Omega(), o() és omega() jelölésekkel, worst/best-case analysissesl?

> Nagyon szeretem, amikor a C kóderek azt állítják, mintha minden kód a világon hard-realtime, 2 kb memórián és egy 4 kilohertzes CPU-val kéne, hogy lefusson. Na, ezek az emberek még nem láttak business kódot, ahol a lényeg mondjuk 45 alrendszer és 25 vendor szoftvereinek az integrálása. Na, ott baromira nem az lesz a lényeg, hogy a keretrendszernek mi a lefutása.Nagyon szeretem, amikor a C kóderek azt állítják, mintha minden kód a világon hard-realtime, 2 kb memórián és egy 4 kilohertzes CPU-val kéne, hogy lefusson. Na, ezek az emberek még nem láttak business kódot, ahol a lényeg mondjuk 45 alrendszer és 25 vendor szoftvereinek az integrálása. Na, ott baromira nem az lesz a lényeg, hogy a keretrendszernek mi a lefutása.

Nagyon szeretem, amikor a Java kóderek azt állítják, mintha minden kód a világon business, 16 GByte memórián és egy 4 gigahertzes CPU-val kéne, hogy lefusson. Na ezek az emberek még nem láttak hardvarközeli kódot, ahol a lényeg mondjuk 45 eszköz és 25 megszakításforrás használata. Na, ott baromira az lesz a lényeg, hogy mi a program lefutása.

Mikor tanulja meg a HUP társasága, hogy nem csak embedded és nem csak business kódok vannak (külön), hanem mindkettő létezik?

Attól még, hogy a te munkakörödben a C alkalmatlan, lehet jó. Attól még, hogy a Java/C#/PHP az enyémben az, lehet jó. Használd arra a nyelvet, amire legalkalmasabb.

Belinkelhetem egy régi hozzászólásom, ami még geleinek is tetszett, lehet elő is fogom keresni ;-)

Hogy visszatérjünk még mindig az eredeti témára:
Hardverközeli kódban nem igazán egészséges, ha elhal a szoftver igaz, mondjuk tömbtúlindexeléssel? Ezért mindig szépen kiírod a tömbindex-ellenőrzést.

Na, akkor mi a különbség aközött, hogy ezt te csinálod meg (és néha elfelejted), vagy a runtime csinálja meg.

Még mindig arról van szó, hogy olyan kódrészleteket, amelyek elengedhetetlenek nagybiztonságú rendszerekhez, és amiket mindig ugyanúgy, mechanikusan kell végrehajtani, miért nem bízzuk a runtimera?

"Még mindig arról van szó, hogy olyan kódrészleteket, amelyek elengedhetetlenek nagybiztonságú rendszerekhez, és amiket mindig ugyanúgy, mechanikusan kell végrehajtani, miért nem bízzuk a runtimera?"
Azért nem bízzuk a runtime-ra feltétlenül, mert abban is simán van ordas hiba, nem tudhatod.
És ha történetesen szoptál is már emiatt, akkor meg sosem fogod.
-----------------------------------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years - but Yoichi is coming up :)

Igen lehet és van is.
Tehát a felelős kód írogatás nem elhagyható követelmény. Ebbe körbe tartozik a tömbindex nem nyakrafaszra inkrementálgatása is.

Konkretizálva a framework/runtime/lib stb.-ben fellelhető hibákat:

Konkrétan memóriamenedzsert kellett írjunk anno, mert a Windowson akkoriban az okos malloc képtelen volt néhányezer pointert eladminisztrálni.
Pedig qrvára le akartam tojni ezt, akartam volna használni rendszer által biztosított erőforrás foglalási rutint.

Másik dolog pl. JAVA JVM.
Egyébként egy qrvajól megírt valami. Viszont adott garbage collector gennyesen ritkán előforduló hiba miatt folyamatosan szivatott bennünket.
Mire kiderítettük, hogy az egyébként jajdebiztos JVM garbage collector baszakszik, eltelt pár hónap.

Ennyit arról, hogy mennyire támaszkodjon az ember maximálisan Library-ker, framework-ökre.

Mindemellett ezzel nem azt mondtam, hogy mindent assemby-ben vagy direkt gépi kódban kellene megírni.
De azt viszont állítom, hogy a felelős programozási gyakorlatot nem helyettesítik a legjobban megírt fejelsztői eszközök vagy framework-ök sem.

Nálam a felelősség körébe tartozik a tömbindex normális kezelése is. Másnál meg nem.
Az, hogy a C-ben megírt OS közeli kódokban egy ilyen buffer overflow mekkora problémát tud okozni, anem a C nyelv problémája, hanem első szinten az OS-é, második szinten meg a programozóé.
JAVA-ban pl az, hogy egy adott hiba nyomán telefossa a logot Exceptionnel, az egyrészt normál működés, másrészt meg semmit sem old meg.
Az algoritmus ugyanúgy szar, ha egy akármilyen hivatkozás azért száll el mert Nul-ra akar az ember metódust hívni, vagy azért, mert olyan helyre akar 1 byte-ot odaírni, ahova nem szabadna.

A "nem szabadna" dolgot a programozónak kell tudni kezelni.
-----------------------------------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years - but Yoichi is coming up :)

Még mindig: azt írtam mindenhol, ahogy ami szükséges a biztonságos kódhoz, és amúgy is minden programozó használja, azt miért nem bízzuk a runtime-ra/fordítóra?

"De azt viszont állítom, hogy a felelős programozási gyakorlatot nem helyettesítik a legjobban megírt fejelsztői eszközök vagy framework-ök sem."
Ez így van. Viszont az, hogy a framework bugos, hamarabb kideríthető, minthogy inkább megírjunk mindent, mert jajjaframework bugos lehet. Lószart.

"Az algoritmus ugyanúgy szar, ha egy akármilyen hivatkozás azért száll el mert Nul-ra akar az ember metódust hívni, vagy azért, mert olyan helyre akar 1 byte-ot odaírni, ahova nem szabadna."
Így van, épp ezért Javaban is dolgoznak a contract-based programmingen, aminél statikus kódellenőrzéssel tudod szépen követni, hogy csinálhatsz-e esetleges NPE-t. Persze ehhez felannotált interfész kell, a kódellenőrzés meg az implementációt ellenőrzi.

És nem, nem az algoritmus a szar, hanem az algoritmus implementációja. MInden algoritmus tök faszán néz ki pidgin Algolban, amikor publikációkban leírják. Ennek ellenére hiába jó az SSL algoritmusa, ha szarul implementálják. És az meg nem az algoritmus hibája.

???

Mondjuk annyi, hogy működik egyrészt, másréyzt meg ha valami mégis hibás benne, akkor tudjuk fixálni, mivel a kezünkben van a forrása és tudjuk, hogy minek hogy kellene működnie benne. Ellentétben a gyárival, ahol azt tudjuk, hogy hogyan kéne működnie, meg a hibát tudjuk esetleg detektálni, ha mégsem. Viszont fixálni már nem fogjuk tudni.
-----------------------------------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years - but Yoichi is coming up :)

Na de honnan vagy te olyan biztos, hogy működik? Formálisan bizonyítottátok, az implementációt ennek megfelelően ellenőriztétek? Honnan tudjátok, hogy nincs benne olyan rejtett eset, amikor mégsem működik úgy, ahogy ti azt gondoljátok?

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

:)

régi malloc elszállt olyan 25.000 pointer allokáció után.
Az általunk implementált meg tesztelve lett 1.000.000 pointer allokációig (mondjuk ez paraméter függő, hogy mennyi memóriát akarunk menedzselni és mennyire húzzuk fel azt a paramétert, ami az ezen a memóriablokkon belül elkezelhető maximális pointer darabszámot állítja = figyeljük okosan a tömbindexet :) ).
E felett Out of memory-t dob, azaz az allokált pointerként Null lesz visszaadva.
És igen, a hívónak le kell kezelnie a Null pointert.

garbage collector funkcionalitást nem kellett hozzá fejleszteni, de az lett volna a következő feature.
-----------------------------------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years - but Yoichi is coming up :)

Valahol onnan indult a beszélgetés, hogy alkalmazásfejlesztés, nem mikrokontroller baszogatás.

"Attól még, hogy a te munkakörödben a C alkalmatlan, lehet jó. Attól még, hogy a Java/C#/PHP az enyémben az, lehet jó. Használd arra a nyelvet, amire legalkalmasabb. "

Na de erről megy a diskurzus: a C-t ott is használják, ahol lenne ezer meg ezer alkalmasabb nyelv.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Aha. Azért meséld már el hogy magyarázod meg a megrendelődnek (látom sehogy), hogy 2x több ügyfél sajnos 8x nagyobb rendszeren lesz csak kiszolgálható, és ha ez nem felel meg neki, akkor versenyt futva az idővel, a kezdeti termékbevezető kampány alatt kell újragondolni az összes algoritmust :D
Platformos vagyok. Tudom mi történik ilyenkor. A fejlesztő előre nem definiálja az algoritmusai komplexitását, a teszteken átmegy, majd amikor először rohanják meg az ügyfelek és összedől, mutogat a platformosokra hogy rakjanak oda nagyobb vasat.
Amíg kismiska bt könyvelő programját írod, addig ez megy. Ha már egy nagyobb cég többezer alkalmazottját kiszolgáló rendszerét nézzük, ott már bizony pazarlod a megrendelő pénzét. Ha egy ekkora cég ügyfélrendszereit nézzük, akkor pedig konkrétan csődbe viszed a megrendelőt, hisz a rendszer bevezetésének a pillanatában látszik, hogy minél több ügyfele lesz, annál veszteségesebb lesz neki a buli.
Ha CPU, memória, diszk és hálózati I/O felhasználási profil szempontjából nem tudod osztályozni a kódod, akkor veszélyes ha kilépsz a kismiska bt szintű melókból. Nagyon.

Szerintem elbeszéltek egymás mellett: ő szoftverarchitektúrára, te meg hardverre gondolsz architektúra alatt.

Ha eleve olyan módszerrel készítik a szoftvert, hogy horizontálisan skálázható (és ez szoftverarchitekturális kérdés, nem hardverarchitekturális), az jelentősen könnyíti a dolgot.

Mindegy, hisz a skálázható szoftver vasakon fog futni.

O(n^3) egy "skálázható" alkalmazás esetén:
100 user = 1 node
200 user = 8 node
400 user = 64 node
800 user = 512 node

Legyen 1 node ára 1000 fabatka.
Az első 100 user esetén a rendszer ára 10 fabatka / user
A 800-adik felhasználónál ez már 640 fabatka. PER FELHASZNÁLÓ.

Ugye nem nehéz business case-t számolni? Minden újabb felhasználó esetén NŐ a felhasználónkénti költségem. Nagyon. Tehát ha 100-nál lőttem be egy jó üzleti tervet, akkor ahhoz kell ragaszkodni, és a többi felhasználót elküldeni, mert ők csak a bajnak vannak. És ne mondd hogy 100-anként legyen egy dedikált rendszer, és akkor "linearizáltad", mert ez pl a való életben azt jelenti, hogy csak a 99 újdonsült haveroddal levelezhetsz, vagy játszhatsz, mert sajnos a régieket más klaszterba rendezte az élet.

Nem én irtam, szóval nem tudom, miért velem vitatkozol, de az állítás ez volt:

"nem érdekes ilyenkor, hogy n^3 vagy n^2-es algoritmussal, vagy n lg n-essel írod meg, mert az input mérete amúgy konstans és a szoftver teljesíti a követelményeket. "

Pont ez a lényeg, ha tudod, hogy az input mérete konstants (és nyilván c egy nem túl nagy szám), akkor nyugodtan használj n^2-es algoritmust, mert belefér. Te kiválóan
bemutattad, ami ebből következik, hogy ha n el kezd nőni, akkor bizony érdemes átgondolni az algoritmust, vagy akár az architekturát (amiben számomra benne van minden,
a hw-től kezdve a különböző cache layereken át az algoritmusokig)

Itt a lényeg:
" az input mérete amúgy konstans" vs "ha n el kezd nőni"

Ugyebár a mérnök a megadott specifikációra készíti el a szoftvert, idő/ráfordítás/költség paraméterekre tekintettel.
És bizony, amint ez a fenti változás megtörténik, máris nem ugyanarról a szoftverrendszerről beszélünk.

Most épp konkrétumok nélkül vagdalózunk. Nálunk pl. az jött ki, hogy jobban megéri egy 2x annyiba kerülő infrastruktúrát alátolni a rendszernek, mint folyamatosan optimalizálással vesződni. Nyilván vannak dolgok, amikor rá kell nézni egy-egy dologra, de ez még mindig olcsóbb. Van intra és public web cucc is.

Nyilván máshol más lesz az arány, nincs univerzális általánosság.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

" A fejlesztő előre nem definiálja az algoritmusai komplexitását, a teszteken átmegy, majd amikor először rohanják meg az ügyfelek és összedől, mutogat a platformosokra hogy rakjanak oda nagyobb vasat."

Amint megvan a performance bottleneck, azt szépen lehet izoláltan cserélni. Mert a jó programozó olyan kódot ír, aminek a részei könnyen cserélhetők. Például ha két metódus közül az egyik n^2-es, a másik meg log n-es, és mindkettőnek ugyanaz az interfésze, akkor azok bármikor cserélhetők, a rendszer más részeihez nem nyúlva.

De persze te is csak a saját oldaladat látod. Nyilván a fejleszők meg arra fognak panaszkodni, hogy megadott határidővel ennyire lehet csak hatékony szoftvert fejleszteni. Tipikusan a managementnek fontosabb, hogy minnél több feature-t lapátoljanak a rendszerbe, mint hogy az jó minőségben készüljön el, és a performance már csak akkor szempont, amikor látszik, hogy lassú, és optimalizálni kellene. Merthogy az hogy néz már ki a roadmappen, hogy a csapat 2 hónapig dolgozik valamin, amiből a user/stakeholder semmit nem lát.

Szóval összességében a lényeg az, hogy könnyű egymásra mutogatni, de tipikusan mindenki kényszerhelyzetben cselekszik és azért sikerülnek ennyire félre a dolgok.

Egyébként meg nem a fejlesztőnek kell egy algoritmus komplexitását definiálnia, hanem annak is egy követelménynek kell lennie, hogy milyen komplex esetekre kell készülni, és mik a követelmények a futásidőre. Mielőtt pedig azt mondanánk egy algoritmusra, hogy kész, ezeket ezt le is kell tesztelni és úgy átvenni azt a fejlesztőcsapattól. Ha a teszten átment, akkor a teszt is rossz volt, nem csak a fejlesztés.

"Másrészt a nagy-O jelölés haszontalan sok esetben. Ugyanis sok műveletet, ami valójában nem elemi, eleminek feltételez. Úgy persze könnyű azt mondani, hogy az algoritmusom n^-es bonyolultságú. Miközben nem az, mert maga az algoritmus által felhasznált "elemi" lépés baromira nem elemi."

Ha jol emlekszem az egyetemre ugye a bonyolultsagot arra hasznaljak, hogy megbecsuljek egy algoritmus lepesszamat az input fuggvenyeben, igy a bonyolultsagot az nem befolyasolja, hogy a lepes az "elemi" vagy 15 "elemi" lepest jelol. O(n) = O(15n). Lasd: https://en.wikipedia.org/wiki/Big_O_notation#Multiplication_by_a_consta…

Szoval nem a nagy-O jeloles a haszontalan, hanem az aki ugy hasznalja, hogy nem tudja ertelmezni :)

Nem, nem arról van szó, hogy multiplication by a constant. Hanem akkor, amikor az egyik elemi lépés valójában nem O(1), hanem O(n) idejű, csak éppen az algoritmus 0(1)-nek tekinti.

Hogy egy példát mondjak: 32/64 bitig valóban O(1) két szám szorzása, felette O(n) a valós műveletigénye. És mondjuk sok számelméleti/titkosítási algoritmus épít nagy számok szorzására.

Arra az O(n) muveleti igenyu szorzasra kivancsi lennek, hogy csinalod :)
Ha kavarjak az O(n) es O(1)-et, akkor persze hogy ertelmetlen lesz az O() hasznalata, de ez nem az O() hibaja, hanem aze aki nem tudja hasznalni...
Egyebkent ha van az algoritmusban O(n)-nel nagyobb komplexitasu komponens, akkor az O(n) elhagyhato (ugye felso becslesrol beszelunk O() eseten), szoval nem feltetlen hiba az O(n)-t O(1)-nek venni. O(n + n^2) = O(n^2)

Igaz, nem O(n), hanem O(n^1.4) valójában.

Nem az a lényeg, hogy kevered az algoritmus leírásában a dolgokat. Hanem az, hogy ami az algoritmusban (a matekban) lehet, hogy elemi lépés (például két szám szorzása), az a valóságban baromira nem elemi lépés.

"gyebkent ha van az algoritmusban O(n)-nel nagyobb komplexitasu komponens, akkor az O(n) elhagyhato "
Ez akkor lenne igaz, ha mondjuk a szorzás nem az 'inner loop' része. És így lesz egy O( n log n) algból O(n^2), csak azért, mert az, amit elemi lépésnek hittek, az valójában nem az.
Például mennyi a mátrixszorzás lépésszáma elméletben, és a valóságban?

Ugyebár, HA a szorzás elemi művelet, akkor a mátrixszorzás lépésszáma O(n^2.7), míg ha nagy számok vannak a mátrixokban, és ezeknek a szorzása nem elemi művelet, akkor ez már O(n^3.1).

Na, ezért lehet félrevezető az O(n) jelölés.

Hogy még mindig értsd: az O() jelölés nem fog semmit mondani arról, hogy a valóságban hány CPU szinten elemi lépés fog történni. Azaz a való életbeli elemi lépés idejét (pl egy gép szorzás 1 nanosec) alapul véve nem fogod megmondani, hogy két mátrix szorzása mennyibe kerül, ha csak azt tudod, hogy az implementált mátrixszorzási algoritmus magasszinten O(n^2)-es a mátrixok méretét tekintve.

De attól még nem lesz igaz, hogy két nagyméretű mátrixot mindig lassabb szorozni - ez bizony függ attól is, hogy a mátrixok elemei hány bitesek.

Hogy értsd: hiába van neked egy mátrixalgoritmusod, lehet adni neki olyan inputot, hogy két n*n-es mátrixot a valóságban gyorsabban szoroz össze, mint két (n-k)*(n-k) méretű mátrixot.

Épp ezért az O jelölés semmit nem mond például futásidő skálázódásáról.

"Épp ezért az O jelölés semmit nem mond például futásidő skálázódásáról."
Egyetlen példa mért futásidejéről nem mond semmit. De skálázódásról beszélünk, ott pedig SOK műveletről, ahol bizony ez már trend = igenis mond valamit. Sőt. Erre való. Egy bárány színe nem mond semmit a populációról (lásd fekete bárány esete), de nézz meg magasról egy 10k példányos csordát, gondolom ugyanazt látod mint mindenki más.

Javaslom a highscalability.com olvasgatását, igen tanulságos hogy azok akik nem csak beszélnek róla, hanem tényleg nagyban űzik a skálázott architektúrák tervezését, építését és fejlesztését mikbe ütköznek és hogy oldják meg.

Ja és ne jelentkezz a Google-hoz, mert ott az első kérdés hogy oké hogy össze tudtad tákolni ezt az algoritmust, de levezetnéd-e az O() komplexitását futásidőre és memóriahasználatra. Ha szebb kérdést kapsz akkor diszk és network I/O is lesz ugyanezen kérdésben ;)

Ne szalmababozzunk mar...
Erre a gondolatodra reagaltam az elso hozzaszolasommal: "Másrészt a nagy-O jelölés haszontalan sok esetben. Ugyanis sok műveletet, ami valójában nem elemi, eleminek feltételez. Úgy persze könnyű azt mondani, hogy az algoritmusom n^-es bonyolultságú. Miközben nem az, mert maga az algoritmus által felhasznált "elemi" lépés baromira nem elemi."

Senki nem beszelt CPU-krol, skalazodasrol, meg futasidorol, nem ertem minek kevered ezeket ide. Algoritmus komplexitasrol volt szo meg O()-rol.

Hogy ertsd: nincs igazad az O() haszontalansagarol. Legfeljebb nem erted mire lehet hasznalni:)

Még mindig: a komplexitás önmagában sokat nem mond, és hasztalan.

Ugyebár a szál onnan indul ki, hogy a Nagyon Alapos Programozó fogja, és bebizonyítja algoritmusainak komplexitását O() jelöléssel.
Csak ez lófasz információt nem hordoz az implementáció viselkedéséről, ezt mondtam én.

Pontosan tudom, hogy mit jelent az O(), o(), Omega(), omega(), de mint mondtam: önmagában ez sok információt nem hordoz.

Innen indult ki az egész: "Honnan tudod hogy hatékony a kódod, ha nem tudod hogy mi a komplexitása (tudod a nagy O betűs) a felhasznált keretrendszernek/libeknek, stb.?"
A nagy O betűs komplexitás lófaszt nem ér (akár a dokumentációban leírva), ha nem tudod, mit tekint elemi lépésnek, és mekkora konstansot használ.

Attól, hogy még tudod, hogy a kódod milyen O-jelölés szerinti komplexitású, baromira nem fogsz semmit tudni az implementációd valódi hatékonyságáról.

Sehol nem írtam, hogy értelmetlen. Hanem önmagában haszontalan információ. Hiába mondod azt, hogy "mivel az XY kódomban használt algoritmus O(n), ezért gyors lesz", ilyen érvelést nem lehet tenni.

De ugye a szálbab arról van szó, hogy a Nagyon Alapos Programozó anélkül nem is tud hatékony programot írni, hogy ne tudná a keretrendszerének elemeiről, hogy milyen a komplexitásuk az O() jelölés szerint.

Csakhogy én még mindig azt mondom, hogy attól, hogy a Nagyon Alapos Programozó tudja, hogy az összes általa használt algoritmusnak mi a komplexitása, még nem jelenti azt, hogy tud olyan kijelentést tenni csak a komplexitások ismeretében, hogy milyen futásideji garanciákat fog a kód valójában mutatni.
Az, hogy egy kódod valójában hatékony-e, csak benchmarkkal lehet megbizonyosodni.

Nem véletlenül mondják nálam okosabb emberek, hogy don't argue, benchmark. Meg azt, hogy premature optimization is the root of all evil.

Elméleti problémák tárgyalásánál nagyon is jó eszköz az O() jelölés, de attól, még, hogy ismered a rendszered algoritmusainak O() jelölés szerinti komplexitását, még nem tudsz mondani semmit a valós karakterisztikáról.

Sokkal több tényezője van egy szoftverrendszer valódi teljesítményének, mint a komponensek komplexitásának O() jelölés szerinti ismerete. Van ugyebár Amdahl törvénye, ha már elméleti teljesítményjavulásokról beszélünk stb.

mert ugye az O(n) az a bemenettől függ. És ugye korábban bemutatták, hogy lehet ott egy c konstans, ami "nem számít". Igen ám, de ez a c konstans lehet a valóságban olyan nagy,
hogy egy adott számú bemenetig mondjuk egy másik, O(n^2)-es algoritmus rommá veri. Szóval ahogy tanult kolléga fentebb írta, bizony mérni kell.

Kevered a szezont a fazonnal. Az O() bonyolultsagra egy mutato. Semmi koze ahhoz, hogy hany sec alatt fut le egy algoritmus. A sebesseg nyilvan fugg a kornyezettol amiben az algoritmus/programkod fut. De ha egy algoritmusban 10 millioszor kell ellenorizni, hogy egy ertek letezik-e a collectionben, akkor azert jo tudni, hogy egy Lookup.Contains() vagy Array.Find() a megfelelo hivas (O(1) vs O(n)).

Ha ehhez a donteshez elkezdesz benchmarkot kesziteni, illetve szarsz ra es majd ha ugy alakul akkor "optimalizalsz" egyszer, akkor meg is erdemled. Meg mindenki aki penzt ad neked ezert :)

A szoftverrendszer teljesitmenyenek nyilvan rengeteg tenyezoje van, es egy O() onmagaban nem sokat jelent, csak mar reg nem errol szol ez a szal.

A szál eredetileg arról szól, hogy hatékony kódhoz szükséged van arra, hogy ismerd az összes framework használt metódusainak komplexitását.

Még mindig: ott a feltételezésed: "ha egy algoritmusban 10 millioszor kell ellenorizni"
Egy mérnök nem arra gondol egyből, hogy "na, most akkor lesz nekünk 10 millió ellenőrzésünk", hanem arra, hogy mit költséghatékony megcsinálni.

Igen, HA performance bottleneck van, akkor már jó tudni, hogy Lookup.Contains() vagy Array.Find(). De amíg nincs performance bottleneck, addig nem kell ezzel törődni. Szép dolog, ha valaki Nagyon Alapos Programozóként minden framework használt metódusaiank komplexitását tudni akarja, de hogy téged idézzelek: aki ezért pénzt ad egy fejlesztőnek, az megérdemli. Ami nem probléma, azt nem kell ugyanis megoldani.
Nagyon sok szoftverprojekt meghal az ilyesféle "na de mi lesz, ha lesz 100 millió userünk" problémák megoldásában, mielőtt elkészülne egy olyan változat, amit 100 user használni tudna.
Egy jó mérnök és szoftverprojekt manager szépen listát vezet azokról a dolgokról, amelyekről tudjuk, hogy gátolja a későbbi skálázódást, és amint ez problémát jelent, akkor megoldják.
Nem arról van szó, hogy szarunk a problémára, hanem arra, hogy nem akarjuk egyből megváltani a világot, mert akkor soha az életben nem fogunk működő terméket piacra dobni.

Egy építészmérnök sem azt mondja, hogy egyből tervezzünk akkora teherbírású hidat, hogy két komplett Vörös Hadsereg is átférjen rajta, hiszen hátha ez lesz. Tanulnunk kéne tőlük :) Szoftverek sokkal sűrűbben omlanak össze, mint épületek.

A szal temaja tobbszor valtozott. Amire en reagaltam, az csupan az O() hasznarol/haszontalansagarol szol.
Nem feltetelezes, hanem felteves volt, hogy "ha egy algoritmusban 10 millioszor kell ellenorizni". Ha nem kell, akkor nyilvan nem ervenyes amit irtam.

"HA performance bottleneck van, akkor már jó tudni, hogy Lookup.Contains() vagy Array.Find(). De amíg nincs performance bottleneck, addig nem kell ezzel törődni"
En meg ezt a hozzaallast ruhellem. Ezert hasznalhatatlanok az uj alkalmazasok a regi gepeken, mert "van bosegesen cpu ido", es ezert kell egy idle Skypenak 120mb memoria, mert "olcso a memoria". Kesobb meg a legritkabb esetben ternek vissza optimalizalni lassu/memoriaigenyes kodot, mert nincs ra igeny/ido/penz.
De ez pontosan ugyanugy nem tartozik az O() temakorhoz, mint a skalazas 100 user vs 100 millio userre.
Egy jo mernok szerintem nehany lepesre elore gondolkodik a szoftver fejlesztesekor es a big picturet nezi, nem csak az ebedszunetig erdekli mi lesz a kodjaval. Egy Lookup.Contains() vs List.Find() dontest nem hivnek azert vilagmegvaltasnak, es egy kezdo programozotol nem is elvarhato hogy tudja, de ha valaki mernoknek hivja magat akkor szerintem tudnia KELL, hogy melyik a jo dontes az adott problemahoz.

A jó mérnök ha a big picture-t nézi, akkor tudja, hogy úgy kell megírnia a kódját, hogy cserélhető legyen az algoritmusa: amint probléma van egy rész teljesítményéből, a rendszer többi elemének megbontása nélkül kidobható. És nem, nem arról beszélünk, hogy ebédszünetig érdekli, és Lookup.Contains vs List.Find.
l
Arról van szó, hogy az eredeti állítás szerint a Nagyon Alapos Programozó nem tud hatékony kódot írni a keretrendszereinek komplexitása ismerete nélkül. És arról, hogy szerintem ez a valóságban baromság. Ha valaki jó mérnöknek tartja magát, az tudja, hogy nem KELL tudnia az összes framework metódusainak komplexitását, ugyanis ennek az információnak a megtanulása, felkutatása is olyan erőforrásokat igényel, amelyek nem érik meg a ráfordítást. Igen, van az a performance optimalizálás, ami triviális, de nem mindegyik az. Egy jó mérnök nem megy el a végsőkig a teljesítmény optimalizálásában, mert tudja, hogy más szempontok is léteznek, mert látja a big picture-t.

A software bloat más téma: nem csak azért eszik sokat a Skype, mert van CPU és RAM bőven. Hanem azért, mert sok mindent csinál. Olyat is, amire esetleg neked nincs szükséged: szépen animálja az emotikonokat, rajzolja a saját kis UI-ját, esetleg XML-alapú vagy más szöveges protokollt használ (hiszen fontos ám az, hogy ember által olvasható legyen a hálózati kommunikáció...)*.
Az, hogy bőségesen van RAM és CPU, az azt jelenti, hogy sokkal nagyobb méretű problémákat is meg tudunk oldani már, mint régebben. Gondolj bele, hogyan néznél egy magas bitrátájú és felbontású filmet régi gépen?

Valamint: még mindig tartom, hogy a komplexitások ismerete papíron nem segít. Attól, hogy egy algoritmusod O(n) komplexitású, attól még lehet, hogy akkora a konstans szorzótényezője, hogy egy másik O(n^2) algoritmust megéri használni azoknál a bemeneteknél, amelyek előfordulnak a valóságban. Maga az O(n) jelölés önmagában nem hordoz olyan információt, ami nélkül ne tudnál hatékony kódot írni. Sőt, félre is vezethet. Nem valószínű, de előfordulhat. Pont azért, mert "a konstans szorzótényező nem számít" és hasonló problémaforrások. Egy jó mérnök pontosan tudja, hogy az O()-jelölésben ismert komplexitás nem feltétlenül szükséges és nem is elégséges a hatékony kód írásához.

*: A Skype 2014 óta a Microsoft Notification Protocolt használja, ami strukturált szöveg alapú. Csomó idő elmegy a parzolással.

Hogy mi az eredeti allitas az attol fugg, hogy hany parentig megyunk vissza a hozzaszolasokban :)

"az O()-jelölésben ismert komplexitás nem feltétlenül szükséges és nem is elégséges a hatékony kód írásához."

Senki nem allitotta az ellenkezojet, ami igaz a hozzaszolasod nagy reszere, mert kb elbeszelunk egymas mellett.

En ennek az elso feletol indultam: http://hup.hu/cikkek/20160410/dot_net_red_hat_enterprise_linuxon_hamaro…
Amit itt be is ideztem (jelezve, hogy mire reagalok): http://hup.hu/cikkek/20160410/dot_net_red_hat_enterprise_linuxon_hamaro…
Es tisztan az O()-rol beszeltem. Programozasi nyelvektol, szoftverektol, frameworkoktol, stb-tol fuggetlenul.

Tisztán az O() jelölés viszont önmagában sokat nem ér gyakorlati szempontból. Pont erről vitatkozunk: egyesek szerint nem lehet hatékony kódot írni anélkül, hogy a használt algoritmusok komplexitását ismernénk.
Majd ugyanő a másik kommentjében ellentmond saját magának: nem elég ismerni a magasszintű O() jelölést, hiszen az "elemi lépés" lehet, hogy nem O(1), hanem O(n) lépésben van implementálva.

Az egész arról szól, hogy igen, hasznos dolog az O() jelölés, de ha a valóságra akarjuk alkalmazni és értelmesen használni, akkor két eset lehetséges:
1. Egészen tranzisztorszintig lemegyünk, és minden szint implementációjának komplexitását ismerve bebizonyítjuk/kiszámoljuk a rendszerünk komplexitását.
2. Megmérjük a keretrendszerünk, a használt algoritmusok komplexitását (azaz nem kell ismernünk az implementációt, mégis tudjuk a tényeket - a mérési eredményről el tudjuk dönteni, hogy O(n) vagy O(n^2) a tényleges komplexitás), majd ezen tények ismeretében cselekszünk: kicseréljük valamelyik alrendszert hatékonyabbra stb.

Hogy hasonló példát mondjak: tegyük fel, hogy Ügyfél úrnak szüksége van az elemi alumínium sűrűségére normál körülmények (hőmérséklet, nyomás) között, 6 tizedesjegy pontossággal.
Két utat választhat:
1. Megbíz egy elméleti fiztikust, aki a kvantummechanikai ismeretek fényében kiszámolja az alumínium sűrűségét 1-2 hónap alatt. Az eredmény totál pontos lesz, megcáfolhatatlan, megbízható.
2. Megkérünk egy kísérleti fizikust, hogy mérje meg. Ő megmondja, hogy ugyan nincs neki éppen dokumentációja (ha lenne, kiolvasná abból), de megméri. 1 hét múlva jön az eredménnyel. Nem teljesen megbízható (hiszen véges sok mérést csinált csak, melyeknek hibája van).

Melyiket választja egy jó mérnök a gyakorlatban?

Soha nem foglalkoztam sem fizikaval, sem kemiaval, sem anyagtannal, sem hasonlokkal, ugyhogy nem tudom (es nem is erdekel) mit erdemes valasztani a peldadban.

Ha szoftvereknel maradunk, amiben ha jol tudom mindkettonknek van tapasztalata, szerintem a jo mernok eldonti mi az az absztrakcios szint amivel foglalkoznia kell az adott problema eseten es azzal foglalkozik. Ha kritikus a futasido, akkor foglalkozik a hasznalt algoritmusok komplexitasaval. Ha az algoritmusban hasznalt "elemi" muveletek komplexitasa nem elhanyagolhato, akkor a jo mernok figyelembe veszi, kulonben nem foglalkozik vele. Ha nincs sok adat, nincsenek komoly szamitasok, fontosabb a gyors fejlesztes, akkor nem foglalkozik a komplexitasokkal...

Szvsz nem fogsz egy univerzalis igen/nem valaszt kapni ilyen altalanos elvi felvetesekre.

A mérnök előveszi a megfelelő táblázatot :-P Egyébként ezt pöttyös labda térfogata, matematikus, fizikus és mérnök felállásban szoktam emlegetni: a matematikus több méréssel meghatározza a labda alakját, méreteit, és ebből kiszámolja a térfogatát. A fizikus vízbe meríti, és megméri a labdára ható felhajtóerőt, amiből meghatározza a térfogatát. A mérnök leolvassa a labda cikkszámát, és megnézi a pöttyöslabda-katalógusban :-P

Nem akarom, hogy elbeszeljunk egymas mellett, en most a webrol beszelek:

"...illetve szarsz ra es majd ha ugy alakul akkor "optimalizalsz" egyszer, akkor meg is erdemled"

Ezert kodolunk(/nank) loose couplinggal. Sitty-sutty cserelheto a problemas komponens. Nem kell mindennek tokeletesnek lennie elsore, mert a kodbazis olyan gyorsan valtozhat az igenyeknek megfeleloen (ld. agilis modszertanok), hogy tok foloesleges napokat, de meg csak akar orakat is arra aldozni, hogy optimalizaltabb kodod legyen, figyelembe vedd a kesobbi* lehetseges igenyeket is.

Most gondold el, van olyan hely, ahol meg arra sincs idod, hogy 10 percet gondolkodj, hogy hogy is kene hivni egy fuggvenyt. Ott arra nem lesz ido, hogy szamolgass, meg optimalizalj, mert amugy tok folosleges, hiszen lehet, hogy a kodod 2 het mulva a kukaban vegzi, mert nem noveli a konverziot. Amelyik AB teszt meg bizonyitott, az meg mehet a refaktoralas utjara, ott mar lehet gondolkozni, de akkor is a kod olvashatosagat elsodleges szempontkent tartva.

*: ahogy valaki mar emlitette is

Van olyan eset amikor egyetertek, es van olyan amikor nem, ez sokmindentol fugg.
Ha 5 perc helyett 15 masodperc amig megnyilik a weboldal amit fejlesztesz, akkor talan megeri fejlesztes kozben elgondolkodni, mert ha csak 4-szer probalod ki a kododat, akkor az mar 20 perc vs 1 perc.
Tisztaban vagyok az overengineering, tul korai optimalizacio problemakorevel es szerintem sem jo, de ugy tunik a hatar, hogy mi szamit overengineeringnek vagy tul korai optimalizacionak, kettonknek nem ugyan ott van.

A helyes sorrend: bugmentesseg, olvashatosag, teljesitmeny.

Es itt arra gondolok, hogy nem fogok azon agyalni, hogy egy Java 8-as Stream API-nak mennyi overheadje van milyen esetben, vagy hogy itt nem fogok bevezetni egy DTO-t, mert az mekkora pazarlas, mert az elso, es legfontosabb a bugmentes, olvashato kod (az utobbi megkonnyiti az elso elereset is). Majd ha kiderul, hogy ez igy mar nem tarthato, akkor lehet rajta optimalizalni. Es itt nyilvan nem logikai optimalizaciora gondolok elsosorban, hiszen azt alapvetoen megteszi az ember ("ha nincs szuksegem ra, nem kerdezem le a backendtol feleslegesen").

Nyilvan szep lenne minden nap tok jokat beszelgetni a kollegakkal, hogy melyik frameworkot is hasznaljuk, vagy hogy ez az algoritmus hatekonyabb, vagy a masik, en is nagyon elveznem, de amig ugy kell kisirni azt, hogy refaktoralasra is jusson ido, addig ez sajnos csak alom (legalabbis ezen a teruleten).

Szerk: alapvetoen veled vagyok, es en is orulnek, ha olyan lenne a webfejlesztes, ahogy te szeretned, de sajnos nem ez a valosag nagyon-nagyon sok helyen. Szoval idealis vilagban igazad van, IRL sajnos altalaban nincs.

SZVSZ:
Tobbnyire egyetertek a hozzaszolassal meg a helyes sorrendel is. Fel ev java tapasztalattal nem kell Stream API overheaden gondolkodni. 15 ev relevans java tapasztalattal meg illik tudni kulon googlezas nelkul. Ezert mas a feladata egy senior fejlesztonek meg juniornak, ahogy masok az elvarasok is.
Az, meg hogy mire mennyi ido jut a projekt eletciklusaban az egy tok mas problema. Sajnos nekem is az a tapasztalatom, hogy refaktoralasra nem nagyon szokott ido jutni, ezert sem ordogtol valo menet kozben optimalizalni (ha van ra igeny es kompetencia, es nem csak a ganyolas megy). Ez sokkal eletszerubb, mint gyorsan lefejleszteni minden featuret aztan imadkozni, hogy a fejlesztes vegen adjanak idot refaktoralni meg optimalizalni. Ha minden feature mukodik, akkor sajnos a szoftver altalaban "kesz"...

( sheridan | 2016. 04. 11., h – 18:52 )

ez már tavaly is idegesített... meg akkor, amikor a Mono MIT licencre váltott... most meg azon gondolkodom, hogy azok az emberi lények, akik ezeket az üzleti döntéseket meghozzák, vajon az alábbiak közül melyik típusba tartoznak bele:

1) a gonoszan vigyorgó, egymásra kacsintó összeesküvők
2) betépett business arcok, akik arról dumálnak naphosszat, hogyan kellene pénzt csinálni
3) ijedt kiscicusok, akiket ütnek-vágnak a főnökeik, hogy legalább potenciális profitot mutassanak fel, különben ki vannak rúgva
4) gátlástalan MIT-licenc hiénák, GPL gyűlölők és szoftverprivatizátorok
5) esetleg feddhetetlen, kiváló szakemberek, akik nagyon jót tesznek úgy általában az egész open source / free software világ jövőjének
6) a hozzám hasonló 60-as IQ-jú csóró drónok által felfoghatatlan összefüggésekben gondolkodó, igazi zsenik, akiktől mindenkinek jobb lesz, aki helyes elveket vall
7) ...

nem... hagyjuk... bennem van a hiba... én vagyok a hülye és ez egy nagyon jó dolog...

Ezt a MIT licenc hiénát nem teljesen értem. Ez olyan, mint az inverz GPL huszár? Nem véletlenül van az, hogy a legtöbb java könyvtár pl. nem GPL licenc alatt jelenik meg, hanem apache (kb. mit szerű alatt), ami egy teljesen más opensource koncepció. Míg a GPL-nél az egész programot "végigfertőzi" egy GPL kód (LGPL illetve GPL+classpath exception talán egy fokkal jobb) addig az apache licenc-nél megtehetjük, hogy nem adunk vissza javítást, VISZONT a gyakorlati tapasztalat az, hogy a legtöbb fejlesztő amennyiben a céges policy engedi, akkor szépen visszaad javításokat, így egymást segítjük, közös bizniszt építve.

( uid_1062 | 2016. 04. 11., h – 19:39 )

"5.3.6.8 Mono Platform and Programs No Longer Provided
Report Bug
#

Starting with SLE 12, the Mono platform and Mono based programs are no longer supported.

These are the replacement applications:

gnote (instead of Tomboy)

shotwell (instead of F-Spot)

rhythmbox (instead of Banshee)"

Just sayin'

( uid_17626 | 2016. 04. 13., sze – 19:11 )

Sejtem mi a cél. Az, hogy Legyen Linuxon is vírus. :)