azért azt tegyük hozzá, picivel bonyolultabb lett a programozás, mint a C64-es időkben 
ott még minden bitnek tudtad a helyét.. mostmeg.. a 150-dik shared library és az 1500-dik rendszer thread után már akkora a káosz, hogy ember legyen a talpán, aki rájön, hogy mondjuk egy microlag miért is történik.
okoskodom, tehát vagyok
40 éve 5-en fejlesztettünk szoftvereket egyetlen miniszámítógépre. Ez úgy zajlott, hogy íróasztalnál papír, ceruza, folyamatábra sablon! használatával írtuk a programot. Amikor a számítógép termináljához kerültünk, szövegszerkesztővel írtuk, javítottuk a programot. Compiler, futtatás, eredmény, hibalista,.., vissza az íróasztalhoz, ahol inkább csak GONDOLKODNI, TERVEZNI, JAVÍTANI lehetett. Ellentétben a terminállal, ahol inkább gyorsan kellett CSELEKEDNI: programot javítani, módosítani,...
Napjainkban minimum egy számítógép ott van a szoftverfejlesztő előtt, így aztán elsősorban a CSELEKVÉS a kézenfekvő. Az átgondolt, tesztelt részprogramok, eljárások, szubrutinok helyett híznak a programsorok, amivel aztán dicsekedhetnek a managerek, hogy milyen sok van belőle.
mezis
Mondjuk az is igaz hogy régen minden jobb volt és akkor még tudták mi az a programozás, bezzeg ezek a mai OOP bűvészek a hipszter functional component paradigmáikkal meg a századik frameworkkel és 3rd party libjeikkel, kezükbe adnál lyukkártyát és nem tudnák hogy eszik vagy isszák.
Hi, i'm new to APHEX TWIN, so i was wondering how much the IQ requirements was to enjoy his stuff. and understand all the underlying themes, because its really complex stuff. I have IQ of 119 but i heard that you need atleast 120 is it true?
Részemről egy okostelefon (főleg egy androidos) egy annyira megbízhatatlan eszköznek számít, hogy nem is rakok rá olyan dolgot, amit lenne értelme ellopni De a valós idejű lehallgatás lehetősége az elég komoly...
"Tepid! Tepid is no good for a star, but it'll do for stardust." (nmlorg/naim)
ugyan.. máshol se jobb a helyzet 
https://9to5mac.com/2019/01/28/facetime-bug-hear-audio/
mindegyik bugos, bár most talán az apple nem annyira, de tőle se várjunk csodákat
okoskodom, tehát vagyok
https://hu.wikipedia.org/wiki/Argumentum_ad_hominem
Ez szerintem a "A körülményektől függő" csoportba esik, amikor is azert teves amit mond, mert nincs tapasztalata szoftverfejlesztesben (legalabbis valaki szerint).
[ Szerkesztve ]
attól, hogy nem tudok tojást tojni, még meg tudom állapítani, hogy a tojás jó-e.
attól, hogy egyesek szerint nincs tapasztalatom szoftverfejlesztésben, még lehet ellenvéleményem a szoftverfejlesztéssel kapcsolatos indokolatlan tolerancia ellen.
attól, hogy egyeseknek fogalma sincs arról, hogy milyen területeken van tapasztalatom, még lehet tapasztalatom.
sorozatosan megtörténik, hogy hülyének nézik itt azt, akinek más a véleménye, mint a többségnek. hogy biztosan azért nem akarok egyetérteni valakivel, mert fogalmam sincs a témáról ( = hülye vagyok hozzá ). miközben a valóság az, hogy tudom és értem, hogy miről beszél, csak más a véleményem.
több száz sebezhetőség egy dsp-ben az igenis tróger munka. igenis legyen javítás. érdekes módon amikor a takata hibája kiderült, akkor nekik kellett "javítást" adni és senkit nem érdekelt, hogy csődbe mennek-e vagy sem (légzsák ügy).
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
amikor egy csapat, szabad szemmel is jól látható mennyiségű pénzbe kerülő raptor ( = mai modern programozás) először lépte át a dátumvonalat, akkor annak kis híján fürdés lett a vége. azért nem peregtek le, mert volt velük egy extender ( = régi (50 éves) ócska programozás)
nem vitatom, tény, hogy a programozás bonyolultabb lett. azt se vitatom, hogy oop meg layer layeren meg api api hátán. azt viszont nem hiszem, hogy ezek a változások egyértelműen az userek javára váltak.
[ Szerkesztve ]
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
SZVSZ azzal kellene kezdeni, hogy az építőelemeket egyesével, hibamentessé tesszük, ez már elve hiányzik.
Utána lehet gondolkodni a Layerek függőségein, és az abból adódó hibákról.
De ehhez az egészhez szükséges egy átgondolt keret, vagyis, hogy valójában miért is csináljuk, és arra mi a legoptimálisabb megoldás.
Itt bukik el az egész, mert sehol nem gondoljak, át az elejétől fogva, és ebből adódik a koton-foltozás.
Ezt úgy mondom, hogy vajmi kevés közöm van a programozáshoz, de látom nap mint nap a hatásait.
Mar a WIN95-os érában is benne volt ez a probléma bőven, hiszen a dll rengetegben sokszor olyan látszólag értelmetlen dolgokat kellett csinálni, hogy valami működő képes legyen az adott program, hogy az hajmeresztő.
Külső szemlélő számára egy csomó összefüggéstelen lépes, de belülről nézve a függőségek, hiányzó komponensek és a regisztrációs adatbázis összefésülése, mert maga a program nem volt rá képes. 
törölve
[ Szerkesztve ]
Okos mérnök a hülyeséggel is kalkulál. Avagy, a "Figyelj oda jobban" tábla nem munkavédelmi eszköz....
Ne C64-re gondolj. Mini- és nagygépekre.
Mainframe-t sikeres támadás még nem ért. A Z/OS kódjában vannak olyan részek, amikhez a 90-es években nyúltak utoljára. Az kiforrott. Nyilván ez egy extrém példa, de az már annak idején is úgy lett kitalálva, hogy ne álljon meg.
Nyilván egy asztali környezetes OS tök más dolog, de azért van pár fokozat a tökéletes kód és aközött a trágyadomb között, ami most szokás.
Nem mellesleg meg lehet nézni a 8086 Domination-t és társait, hogy mire képes az optimalizálás PC-n. Meg a legtöbb Apple terméket, amiket lehet szeretni, vagy nem szeretni, de azok igen rendesen össze vannak reszelve a hardverrel (persze, mert ott meg lehet ezt csinálni).
@GeryFlash : Nem volt jobb minden régen, de azért a ló kissé elszaladt a mindenáron minél gyorsabb szoftverkiadás irányába. Most meg már örülsz, ha elsőre működik valami :S
Mutogatni való hater díszpinty
Persze. A feleséged tudja a te telefonod kódját, ezért ő használni tudja a telefonod. Esetleg a jelszavaid is. Nos ha megtudja harmadik fél is, akkor pánikszerűen átállítod a hozzáférhetőséget.
Itt is ez történik. Egy zárt kör backdoort kér, azon hozzáférnek a rendszer bizonyos elemeihez, vagy bizonyos műveleteket tudnak végezni. Ez eddig backdoor.
Viszont ha kiderül, onnantól kezdve lesz veszélyes a rendszerre nézve, szóval az már sebezhetőség, hiszen nem tudhatod, ki mit fog csinálni vele.
Nyilván a backdoor is sebezhetőség, de ha csak egy szűk kör tudja, az kontrollálható.
[ Szerkesztve ]
2024: nem lesz kegyelem a HMD-féle hulladékgyáraknak.
Ez nem igaz. Kerülnek ki belőle drive-erek is, bizonyos funkciók távoznak, bizonyosak meg bejönnek a Windows-nál is.
2024: nem lesz kegyelem a HMD-féle hulladékgyáraknak.
Nnnaaa megnyugodtam, az telómban Exynos van. 
Mert lakni, muszáj.
Ez durva volt.
Jobb is, hogy a Samsung nem a szar SD-s húszasait hozta ide, mi?
2024: nem lesz kegyelem a HMD-féle hulladékgyáraknak.
Nesze neked, Agile... Égnek áll a hajam, amikor azt olvasom, hogy naponta több tucat build megy ki prod rendszerekre.
https://www.coreinfinity.tech
több tucat? a hupon büszkén hirdette magát egy cég, hogy náluk napi 10 ezer deploy a cél. tízezer... [link]
annyit hibázni se tudok, hogy mindegyikre jusson legalább egy bug...
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
Csak nem gondolod, hogy több száz sebezhetőséget kielemeznek
Dehogyis!
"nem létezik hibamentes szoftver"
merugye a tisztelt programolok basznak matematikailag bizonyitani, hogy a megoldas az adott (resz)problemara ugy jo lesz.
marad az AS modszer , megyunk tovabb.
Első AMD-m - a 65-ös - a seregben volt...
Hát, általánosságban lehetett volna írni róla. Kis keresgéléssel máris volt ilyen jellegű portálon bővebb cikk.
Mutogatni való hater díszpinty
"átgondoltságról szólt az informatika, ld. még Unix, és származékai"
az Unixxal semmi bajom, de a c... na az aztan az atgondoltsag csucsa.
[ Szerkesztve ]
Első AMD-m - a 65-ös - a seregben volt...
"nem létezik hibamentes szoftver": de, létezik. a hírek szerint a vms nucleusát bebizonyították.
"rengeteg hiba a szoftverekben és ebből sok nem trehányság miatt van": nagyon érdekelne a te álláspontod arról, hogy hogyan kerül hiba a szoftverbe, ha nem trehányságból.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
Pixi 3a, repülö üzemmódban, semmi mobilnet, no wifi kapcsolat. Minden off.
Hallgatod a zenét a szobában más eszközön és kiirja a Pixi éppen mi szól. Hogyan? Már egy egész adatbázis van a telefonom vagy mégis kommunikál valamilyen távoli adatbázissal valamilyen "csatornán" suttyomban? 
Mire gondolsz a C-ben?
"Ezt akartad, hát nesze" nyelv Néha tényleg fura, hogy még mindig használatos.
De nézd meg a vetélytársakat, voltak komolyabban összerakottak is.
Mutogatni való hater díszpinty
a kalapácsot se illik hibáztatni azért, mert néha az ujjadra ütsz...
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
Oke, de az en hozzaszolasom csupan arrol szolt, hogy de bizony, #78 az szemelyesdekes. Szoval ezt a moderator uraknak kene irni.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
"nem is rakok rá olyan dolgot, amit lenne értelme ellopni"
Jellemzően nem a mobilon lévő fájlokat lopják el, hanem a profilozott személyes adatokat, használati szokásokat, statisztikákat. De ezt a weboldalak is megteszik, ma már a legtöbbjük használ valamilyen profilozó, ujjlenyomat készítő scriptet. És elég sok desktop alkalmazás is. A jelenség nem korlátozódik a mobilokra. Szerintem ez ellen még egy Librem 5 sem elég hatékony. Az Apple volt az első, aki elkezdte követni a felhasználó fizikai mozgását a GPS alapján. Aztán a Google is csatlakozott, persze csak a felhasználó érdekében, hogy lásd merre jártál...
Az intelligens ember csodákra képes. Az idióta ember bármire.
Matematikailag nem kell bizonyítani semmit. Unit teszteket kell írni, de hiába van unit tesz, ami bizonyítja, hogy a megírt programkód jól működik, mert még mindig rengeteg helyen elvérezhet a dolog (pl az integrációnál).
***
csak eppen a C az a rosszul csiszolt lencseju szemuveg, ami miatt neha nem ott latod a szoget, ahol valojaban van.
Első AMD-m - a 65-ös - a seregben volt...
1817-ben meg azt tanitottak, hogy a kod helyesseget lehet bizonyitani.
nem vitatva a teszteles fontossagat szvsz a tesztek 90% -at meg lehetne sporolni, ha bizonyitottan helyes lenne a kod.
de hat uj idok uj teveszmek.
sokaig eljen az AS modszer, arra lehet igazan ujabbnal ujabb vad "ha igy csinaljuk tutti jo lesz" kitalaciokat epiteni.
Első AMD-m - a 65-ös - a seregben volt...
"az Unixxal semmi bajom, de a c... na az aztan az atgondoltsag csucsa"
Akkor te nem számítod az sh-t illetve Bash-t a Unix részének. Na az... ahhoz képest a C nyelv egy csiszolt gyémánt. Persze, tudom, nem szabad benne hosszabb scriptet írni, de mégis sok helyen az van.
Te milyen területen fejlesztesz? Milyen jellegű alkalmazásokat tudsz leszállítani ezzel a megközelítéssel? Mert nekem ez egyáltalán nem tűnik a valóságban alkalmazhatónak, kivéve nagyon speciális eseteket, amik nagyon ritkák.
[ Szerkesztve ]
Milyen ertelemben kell? Kulonben borton? Vagy kulonben csodbe megy a ceg? Mert amugy egyik sem igaz. Szerintem vannak modszerek, valamilyen sikerrel alkalmazzak vagy nem alkalmazzak oket, es van a felhasznalo-elegedettseg meg a piaci siker. Ha valami kellene, az nem ezekkel kapcsolatos, hanem inkabb azzal, hogy a termek, amit arulnak teljesiti vagy nem teljesiti a specifikaciot. Egyedi szoftverfejlesztesnel szoktak ezt szerzodesben szabalyozni, tehat van definialva, kritikus, sulyos stb. hiba, amit haladektalanul, x idon belul, kovetkezo release-re, stb. javitani kell. Szerintem annak az iranynak lenne ertelme, hogy felhasznaloi szoftvereknel ilyen szabalyozast bevezetni.
Úgy kerül, hogy nem lehet 100%-osan funkcionális lefedettség szerint tesztelni. A kód lefedettség is hasonló probléma. Egy átlagos Business vagy Project management software például nagyságrendekkel bonyolultabb mint egy számlázó szoftver (néha akár több száz 3rd party rendszerrel vannak integrálva), még egy kis módosítás is óriási QA költséggel jár.
Persze elméleti lehetőség megvan a 100%-os lefedettséghez, de az többnyire olyan nagy erőforrás befektetéssel járna, hogy nem érné meg elkezdeni sem a fejlesztést.
***
A teszteléssel tudod bizonyítani, hogy helyesen működik egy szoftver, matematikailag nem. Vagyis persze lehet, hogy lehetséges, de mit gondolsz, hány évezredbe kerülne mondjuk a Microsoft Word helyes működésének bizonyítása matematikailag?
***
Miért kell unit teszteket írni? Mert az az első lépcső a minőségbiztosításban, és ezzel érhető el az, hogy a lehető legkevesebb pénzt kelljen költeni QA-ra, mivel már a fejlesztés nagyon korai szakaszában kiderül sok programozói hiba, és minél korábban javítják ezeket (itt ugye még az előtt javítja a fejlesztő, mielőtt egyáltalán felkerül a kód a repositoryba), annál olcsóbb a javítás.
Szóval ha valaki nem ír unit teszteket, az gyakorlatilag növeli a szoftver fejlesztésének költségét.
***
Aruld mar el pontosan milyen szoftverfejlesztesben veszel reszt ahol te a kodjaid helyesseget folyamatosan matematikailag bizonyitasz? Vagy csak belokted ide hogy hat igy kene de persze te se igy csinalod?
Hi, i'm new to APHEX TWIN, so i was wondering how much the IQ requirements was to enjoy his stuff. and understand all the underlying themes, because its really complex stuff. I have IQ of 119 but i heard that you need atleast 120 is it true?
én azért látok differenciát a "fullosan 100%" meg a cikk szerinti 400 hiba között. ha egy dsp-ben 400 hibát találtak, akkor az 1-2%-os lefedettséggel volt tesztelve, ha egyébként a hiba nem szándékosan került bele.
továbbra is fenntartom a véleményem: amit a szoftveriparban megengednek maguknak, az vásárlói szemszögből nézve tűrhetetlen.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
A unit test csak a funkcionalitást ellenőrzi, a biztonsági réseket nem. Biztosítja, hogy ugyanazt a funkcionális hibát ne kövesd el még egyszer, de semmi többet.
https://www.coreinfinity.tech
Ennyi
Amúgy a 400 hiba valószínűleg valamilyen hiányosságok variációiból jön össze. Valamilyen jogosultság-emeléshez vezető bugot mondjuk ötféleképpen lehet kihasználni, ilyesmi.
@hokuszpk : Merthogy...? Nem oda esnek a memóriacímek, vagy mi?
@zizidor : Meg egyéb kreatív felhasználások, amikre nem szokás gondolni, és akkor hülyeség az egész.
Mutogatni való hater díszpinty
De itt most általánosságban beszéltünk a tesztelésről. A unit teszt csak az első lépése a tesztelésnek, de már ott ki lehet szűrni rengeteg hibát, amelyek jelentősen megdrágíthatják fejlesztést, amennyiben nem találják meg azokat a unit tesztekkel.
***
Nyilvan azert tetted fel magadnak a kerdest, mert en nem azt kerdeztem, amit megvalaszoltal.
Googlezd meg: "unit testing waste", es kiderul, hogy nem eleg, ha oda tudod rakni a pipat a unit teszt melle, ilyen ertelemben nem kell. Jol mukodo process, az kell, olyan ertelemben, hogy feltetele a hosszu tavu ugyfelelegesettsegnek.
Nem elég a unit teszt, nem is állítottam, de alapvető dolog a szoftverfejlesztésben.
Alapvetően 4 tesztelési szint van:
1. unit test (fejlesztő)
2. integration test (tesztelő)
3. system test (tesztelő)
4. acceptance test (ügyfél)
Mind a 4 szintet le kell fedni, és minél korábbi szinten kiderül egy hiba, annál olcsóbb a javítása. Ezért van szükség unit tesztekre, mert úgy olcsóbb a fejlesztés, ha már ott meg vannak fogva a unit szintű hibák, mert hogy lesznek unit szinten is, hiszen egy fejlesztő sem tökéletes, mindenki követ el hibákat.
[ Szerkesztve ]
***
Azert a unit es integration kozott meg szokas emliteni a component testet.
Hi, i'm new to APHEX TWIN, so i was wondering how much the IQ requirements was to enjoy his stuff. and understand all the underlying themes, because its really complex stuff. I have IQ of 119 but i heard that you need atleast 120 is it true?
Ezt az egészet nagyon parának tartom, hogy "ja, hát az Android az úgy is tiszta lyuk, mindenki tudja". Mindenki eszerint is használja? Google is ezt javasolja? Mert azt gondolnám sokan ugyan azt a Google fiókot használják telefonon, mint a PC-n, nem valami kukázható random fiókot. Akkor annak "elrablása" elég ciki lehet, mert valószínűleg ott az elsődleges e-mail fiókod, és csak hogy egy gondot említsek, más oldalak oda küldik az "elfelejtett" jelszót. Ott az összes kontaktod is, Google Docs, Google Drive ha használod, stb. Aztán persze, FB, Twitter, ha valaki fontosabb dolgokra is használja, nem kellemes ha valami "nyomkodja" helyetted. Aztán, ha van kétfaktoros belépés valahova, nagyon sokszor a második faktor a mobiltelefonon keresztül valósul meg. Aztán, a telefont nagyon gyakran rádugja az ember a PC-jére hogy fájlokat másolgasson, szóval az sem kizárt, hogy az egyik átfertőz a másikra, és akkor az elég tuti, ha megvan mind a kettő, pl. OTP Direktemet úgy lazán lehetne használni. Nem tudom mennyire volt már ilyen. De nem értem, hogy lehet ezt elbagatellizálni. Ezt a "zsebszámítógépet" már sokan többet használnak, mint a "rendeset", és egyre inkább ezeken zajlik az élet.
Nyilván, a biztonsági(!) frissítéseknek úgy kell mennie mint Windows-on, különben megette az egésze a fene. Azaz, nem függhet a vastól, hogy megkapom-e. Legalább is amíg nem valami igazán ősi telefontról van szó.
Mert mi lesz ha aggodsz, jobb lesz? Remelem nem kell mondanom hogy BARMIT fel lehet torni. Csinalhatsz barmit ha megvan a kello szandek ugyse tudsz mit csinalni. Fogadd el hogy ez ellen nem tudsz mit tenni. Mi nyugtasson meg? Az erre valo esely.
A kerdes hogy megeri-e belerakni az energiat. A valasz az hogyha nem vmi tomegesen jol autamatizalhato dolog akkor nem igazan. Attol rettegni hogy a mobil SOC-ban levo adatokbol visszanyernek adatokat es elutaljak ezek utan az OTP netbankodon levo penzt egy maltai offshore szamlara olyan mint mindennap rettegve kimenni az utcara hogy jon egy gombvillam es agyonb*sz.
Ha nem akaord bevallalni ezt a 0,01% kockazatot es nagyobb biztonsagot akarsz akkor hasznalj iPhonet. De attol rettegni, hogy a biztonsagi frissitesekkel honapok/evekkel lemarado Androidos keszulekdet majd a Qualcomm SOC-ban levo serulekenyseggel fogjak torni ...
Hi, i'm new to APHEX TWIN, so i was wondering how much the IQ requirements was to enjoy his stuff. and understand all the underlying themes, because its really complex stuff. I have IQ of 119 but i heard that you need atleast 120 is it true?
Pont ez az, hogy egy normálisan működő OS-t túl nehéz törni.
Az Androidnak ez is az egyik baja + a rá írt appoknak. Nyilván az ember használja, mert nincs más, de én örülnék, ha többszereplős lenne a mobil OS piac, pláne annak, ha a telefonokra is lehetne többféle OS-t telepíteni.
És attól még, hogy nem tudunk vele mit csinálni, leírhatjuk, hogy nem jó ez így.
BTW én csak az e-maileket szinkronizálom le telefonra, a file-jaimat nem. Azt szépen másolom kézzel, ritkán kell.
Amikor Android telefonom van (mert most éppen iPhone - az Alma legalább hosszú supportot ad), akkor az lehetőleg Lineage -s, így kevesebb kicsit a gyártói cucc, meg legalább nyílt OS van rajta. (Sajnos a céges gyári OS-es, és saját fiókkal megy az is - pl. miért nincs normális enterprise management eszköz ilyesmire?)
A tabletemen meg Play Services sincs már
[ Szerkesztve ]
Mutogatni való hater díszpinty
Nyilván az ember használja, mert nincs más, de én örülnék, ha többszereplős lenne a mobil OS piac, pláne annak, ha a telefonokra is lehetne többféle OS-t telepíteni.
Igen. felhasználói szemmel jobb lenne. Ma (majdnem) ott tartunk, mint a PC piacon. Itt ugyan van 2 féle OS, de az meghatározza a hardvert is.
***
mondjuk az apple pont a legallja.. elég megnézni az xcode vagy az itunes értékelését, nesze neked almás életérzés meg ökoszisztéma mondom ezt úgy, hogy 2 asztali apple van itt a sarokban, meg pár ios eszköz. Az ios eszközök még úgy ahogy, de az asztali osx az nálam az ipari hulladék szinonímája. A régebbi i5-ös a pentium 3-as időket idézi, sok sok homokórával(ami az applenál a pörgettyű), az újabb i5-ös már a pentium 4, legalább nem percekig tart a pörgettyűzés. Mindkettőt újonnan vásároltam, és utálom is mindkettőt, mert a windows ennél jóval lassabb processzoron szaladt, futott száguldott (összemértem a pcmmel, mert azthittem valami átverés van), ráadásul a microsoft visual studio egy remekmű az xcode-hoz képest.
okoskodom, tehát vagyok
