[ Space Beer @ 30.12.2018. 22:42 ] @
Pre dvadesetak dana je Microsoft objavio da odustaje od svoje EdgeHTML tehnologije i da će svoj browser prebaciti na Chromium. Prosečnog (Edge) korisnika to i ne zanima puno. Nama je svejedno šta je u pozadini browsera ili bilo kog drugog programa, sve dok taj program služi svojoj svrsi.

Međutim, u ovom slučaju radi se o potezu koji je veoma bitan za sve (PC) korisnike. Prvo, sada pored Chroimium-a, ostaje još samo Firefox kao browser koji je (sa svojim engine-om i pratećim tehnologijama) dostupan svima. Odnosno, Chromium-based browseri će se uskoro naći kod 80-85% korisnika, s trendom daljeg rasta. Ako zanemarimo Safari sa svojih nekoliko procenata, i koji svakako nema problema sa sredstvima za razvoj, jedina prava alternativa zavisi upravo od Google-a. Jer razvoj Firefoxa zavisi od novca koji Gugl daje Mozili kako bi njihov pretraživač bio podrazumevani nakon instalacije. Ukoliko udeo FF-a bude padao, Gugl će imati manje interesa da daje novac. Još ako se ima u vidu da je FF prvi izbor linuksaša i privacy advokata, tj. da će im pretraživač biti DDG, StartPage, SearX... pitanje je da li se Guglu isplati to planinarenje. Mada nije da nemaju novca za bacanje. Tako da ćemo doći u sitaciju kao pre 15-ak godina kada je IE, odnosno Microsoft imao monopol u ovom polju. S tim što je sada situacija znatno lošija. Jer za razliku od tog perioda, kada smo browser koristili za pretragu, čitanje vesti i zanimljivih strana na netu, sada se najmanje koristi za te svrhe, a najviše kao alternativa klasičnom aplikativnom softveru.

Danas je čest slučaj da se neki novi program/servis nudi prvo preko veba i mobilne aplikacije, a kasnije možda i izađe i desktop verzija "optimizovana" za standardnu PC upotrebu. S jedne strane, korisnici su već navikli da za skoro sve što rade na računaru, rade iz browsera - mail, audio i video sadržaj, im/voip, office... a sve češće su tu i ozbiljniji alati za poslovnu primenu - CRM/ERP, software development, CAD, project management.... S druge strane, developerima to olakšava posao, jer vrlo lako mogu da podrže različite (sve) platforme, lakše ažuriraju softver, testiraju, popravljaju bagove itd. U situaciji kada više različitih browsera ima značajan udeo (5+ %), mnogi se trude da ih podrže sve, ili većinu. U situaciji kada jedan ima veliku većinu, mnogi ne žele da troše resurse na druge browsere. Jednostavno će navesti da njihov program radi samo u određenom browseru, u određenom OS-u i to je to. Nekada možda postoji tehnički razlog iz kog je nešto nemoguće portovati, ali najčešće je to odluka developera, tj. njihovog menadžmenta. Što na kraju ima negativan uticaj na (mnoge) korisnike.

Npr. sećam se perioda od pre 3-4 godine i stare Opere (v12). Za mene je to bio jedini normalan browser, sa gomilom prednosti u odnosu na konkurenciju. Ali sve je to bilo uzalud, jer je bilo sve više stranica i sadržaja koji jednostvano nije funkcionisao u tom browseru. Tada sam koristio ne beta verzije alternitivnih programa, već alfa (npr. Otter, koji je sada stigao do v1.0). Jer su tadašnje ozbiljne alternative (Opera 15 , Firefox...) postale Chrome klonovi. U međuvremenu su se srećom izdvojili i uz Vivaldi postali znatno bolji programi. Ali to što su sadašnji alternativni programi, koji su po mogućnostima i nekim karakteristikama ispred Chrome-a, bazirani na istoj osnovi (Chromium), ne znači da će stranice i sadržaj optimizovan za Chrome raditi podjednako dobro i u tim programima (npr. Vivaldi, Brave, Opera, Falkon, sada i Edge). A nisu retki ni primeri da ne rade uopšte. Ovo je jedan od primera iz Vivaldi browsera:
https://i.imgur.com/YrUwKm3.png

Pri čemu čak i promenom user-agenta sa odgovrajućom ekstenzijom problem ostaje. Dok s druge strane, Firefox sa tim "rešenjem" može da premosti ovo ograničenje. Ali to nije ono što ja kao Firefox korisnik želim. Jednom sam imao problem prilikom kupovine karte preko Alitalia sajta i nakon kontaktiranja podrške, rekli su da preporučuju Chrome za on-line kupovinu. Mislim da od tada nisam više leteo avionom te kompanije

Drugi razlog zašto je ova odluka loša je to što Chromium nije samo osnova skoro svih web browsera, već sve češće i drugog aplikativnog softvera. I to uglavnom kroz Electron, čiji je "vlasnik" od skoro Microsoft. Mislim, to je dobro za MS i mnoge developere, ali opet loše za korisnike. Ta kombinacija je, uz neke druge alate postala standard za novi aplikativni softver. I developeri se hvale kako podržavaju (skoro) sve platforme. Što je dobro. Međutim, ono što nije dobro je što takvi programi uglavnom nisu optimizovani ni za jednu. I ne mislim samo na performanse, već i na GUI i samo korišćenje programa. Jednostavno, ako je nekome fokus na web (browser) varijanti, teško da isti program može napraviti i kao standardni PC program sa GUI/keyboard elementima na koje smo navikli i koji nam olakšavaju rad. I dok u nekim situacijama to može imati smisla, često su takvi programi tromi, troše više resursa i fale im opcije koje imaju "tradicionalni" programi pisani sa jasnim ciljem - da budu korisni, efikasni i zadovolje potrebe korisnika.

Ako se na sve ovo dodaju i UWP programi, koji su slični Electron varijantama (UI za web/mobile, tromost, nedostatak opcija), nameće se pitanje kuda ide razvoj aplikativnog softvera za PC. Tj. da li je glavni cilj napraviti upotrebljiv program prema potrebama korisnika, ili napraviti nešto reda radi, da bi menadžment kompanije mogao da se pohvali i opravda utrošene resurse.

Ja razumem da se danas sve seli u oblake, da svi hoće pristup svemu na svim uređajima, da je grupno korišćenje među prioritetima i slično, ali sve se to može postići tako da se na svakoj platformi može izvući maksimum iz postojećih resursa. Na PC-u su to veliki ekran velike rezolucije (ili više njih), miš (sa 6+ tastera), tastatura (sa gomilom prečica)... Jedan od najboljih primera je (bio) MS OneNote. Odlična desktop verzija (po mom mišljenju najbolji program te vrste), odlična mobilna aplikacija i pristup iz browsera. Integracija sa Onedrive-om, deljenje i saradnja su takođe dobro odrađeni. I upravo je tu MS odlučio da napravi rez, ubije win32 desktop verziju i ostavi korisnike na UWP varijanti. Ne znam koji je razlog, ali znam da MS ima resurse da razvija takav progam.

I umesto da se programi razvijaju tako da korisnici dobiju najbolje moguće rešenje (MS office + Office online, Libreoffice + Collabora, QOwnNotes + Nextcloud notes, Thunderbird + bilo koji webmail, Keepassxc + browser plugin), dolazimo u situaciju da je fokus na izmišljanju tople vode pakovanju web stranice u "drugačiju" formu. Pa tako imamo programe kao što su wavebox, rambox, franz, station... koji se hvale kako su tu da povećaju produktivnost. Neverovatno je da su korisnici pristali da instaliraju program koji će im prepakovati loš(ij)e web rešenje (npr. google docs) u "desktop" varijantu koja je po svim parametrima iza tradicionalnih paketa kao što su MS office, Softmaker office, Libreoffice... Nije čak ni dodavanje dve kante RAM-a toliki problem, ako bi to zaista radilo bolje. Ali ne radi. Mogu da razumem da se takva opcija koristi ukoliko za određenu platformu ne postoji drugo rešenje, a korisniku je neophodan određeni program. Onda ovako nešto ima smisla:
https://www.dedoimedo.com/computers/manjaro-ms-office-online.html
Ali nekad stvari odu predaleko
https://libre.lugons.org/index...brijum-nivo-tri-novo-iskustvo/

I na sve ovo, imamo ekspanziju servisa koji nam nude da vrte naše programe na njihovom hardveru, kako mi ne bismo razmišljali o održavanju sistema.
https://liquidsky.com
https://shadow.tech/usen
https://www.ovh.com/world/cloud/cloud-desktop/infrastructure/

Možda još uvek nismo došli do toga da je PC samo "terminal", a sve ostalo "negde tamo", ali čini mi se da smo veoma blizu tom scenariju. Evo i jednog teksta na temu odakle su neki od navedenih komentara, između ostalog i (link za) naslov
https://daringfireball.net/201...and_the_decline_of_native_apps
Jedino što je neko mislio da će to pogoditi samo Windows, ali nema razlike ni sa drugim sistemima
[ Ivan Dimkovic @ 30.12.2018. 23:13 ] @
Citat:
Space Beer
Možda još uvek nismo došli do toga da je PC samo "terminal", a sve ostalo "negde tamo", ali čini mi se da smo veoma blizu tom scenariju.


Kako za sta i kako gde.

Za poslovne aplikacije, virtualizovani desktopi su "stvar" vec godinama, za gaming i profesionalnu upotrebu gde su faktori poput rezolucije, frejmova u sekundi i latencije bitni to onda postaje malo komplikovanije i nije bas lako ostvarivo sa zadovoljavajucim rezultatima svuda.

Ali ne i totalno neprakticno resenje za urbane regione sa gigabitnim netom sa minimalnom latencijom do najblizeg provajderovog datacentra na na kojima su ubodeni "gaming" blade-ovi sa jakom grafikom a od/do korisnika ide kompresovani A/V signal. Ali ovakav setup je moguc trenutno samo ili u enterprise okruzenju (sa svojim DC-om) ili u bogatim delovima gradova gde ces naci dovoljno korisnika koji bi platili takav subscribtion.

Recimo, nesto tipa, obican net: $59,99 za Gbit/s (lupam) + ako hoces da uvek imas "max" gaming PC, eto onda je $129.99 mesecno. Ti dobijes "glupi terminal" koji je u stvari glorifikovani monitor sa H.265 (ili sta god) dekoderom, USB i mreznim portom a provajder na svojoj strani ima rackove "gaming" masina (tj. servera koje particionise na "gaming masine").

Ne moras nikad da brines o upgrade-u, da kupujes graficke, memoriju, srafis, kacis, budzis drajvere... nego samo lepo odaberes pretplatnicki plan i uneses broj tvoje kartice :-)

Elegantno, ali zahteva dovoljan broj potencijalnih korisnika na malom prostoru zbog latencije.

@edit, sto se Electrona / JavaScripta svuda tice... ta bitka je odavno izgubljena. U principu problemi tog pristupa ce, kao i uvek, biti "peglani" jacim hardverom. Mobilni GPU-ovi imaju jos prostora da budu jaci i onda se sve svodi na prostu racunicu da je jeftinije ciljati na novu generaciju hardvera nego pisati visoko-optimizovani softver. Tuzno ali istinito.
[ Ivan Dimkovic @ 30.12.2018. 23:30 ] @
Citat:

Ja razumem da se danas sve seli u oblake, da svi hoće pristup svemu na svim uređajima, da je grupno korišćenje među prioritetima i slično, ali sve se to može postići tako da se na svakoj platformi može izvući maksimum iz postojećih resursa. Na PC-u su to veliki ekran velike rezolucije (ili više njih), miš (sa 6+ tastera), tastatura (sa gomilom prečica)... Jedan od najboljih primera je (bio) MS OneNote. Odlična desktop verzija (po mom mišljenju najbolji program te vrste), odlična mobilna aplikacija i pristup iz browsera. Integracija sa Onedrive-om, deljenje i saradnja su takođe dobro odrađeni. I upravo je tu MS odlučio da napravi rez, ubije win32 desktop verziju i ostavi korisnike na UWP varijanti. Ne znam koji je razlog, ali znam da MS ima resurse da razvija takav progam.


Ma nisu samo UWP aplikacije krive, i "native" aplikacije trce danas na milion framework-a i osim ako >specificno< nisu optimizovane na odziv (tipa da UI bude "smooth as butter" i da se ne ceka ni na kakvu operaciju vise nego sto je to minimalno moguce) vucaraju se.

Mislim moja "radna" masina ima 128 GB RAM-a, 36 jezgara (fizickih) na 3.3 GHz, 1080 Ti grafiku, NVMe SSD-ove - dakle, sve prilicno brz hardver, i onda startujes Visual Studio i on nesto drnda 10-20 sekundi ponekad. Office isto, cesto zaglupi na par sekundi.

Isto neke Windows komponente, gotovo sve pravljene u .NET-u tacno osetis "sporost" UI-ja.

Onda iz zezanja uzmes i instaliras Windows 2000 u virtuelnoj masini na ovoj gore masini i gledas kako se stvari startuju >trenutno<. Ceo OS stane u L3 kes jednog od dva procesora na sistemu :-)
[ Shadowed @ 30.12.2018. 23:37 ] @
Ima se sta reci i na drugo napisano, al' drugi put :) Sto se OneNote-a tice, 90% sam siguran da ce sledeca verzija biti na Electron-u.
[ negyxo @ 31.12.2018. 01:04 ] @
Citat:
Ivan Dimkovic:
Mislim moja "radna" masina ima 128 GB RAM-a, 36 jezgara (fizickih) na 3.3 GHz, 1080 Ti grafiku, NVMe SSD-ove - dakle, sve prilicno brz hardver, i onda startujes Visual Studio i on nesto drnda 10-20 sekundi ponekad. Office isto, cesto zaglupi na par sekundi.

Khm, posto sam malo radio sa VS API-em (tj. dosta, vise od godinu dana sam posvetio na pravljenju nekog plugina), mogu ti i reci sta je najveci problem VS-a: legacy + kompleksnost. I dan danas, VS je dosta COM based, i mnogo stvari je bazirano na C++ bibliotekama, a opet i dosta stvari je ugurano u postojecu arhitekturu da ide kroz .NET (ceo MEF). Najveci problem koji sam ja primetio sa VS-om je sto postoji jedno milion servisa na koje se attacujes i ti prakticno imas stotine, ako ne i hiljade poziva u sekundi koje handlujes za razne stvari (dokument je aktiviran, dokument je snimljen, undo/redo pozove nekih 10 funkcija za svaku izmenu, komanda je execute-ovna gde je svaki WindowsMessage od tastature i mise preveden u neki interni VS-ov message koji se dalje procesira na vise nivoa itd.). Mislim da sam ja bio samo dotakao delic onoga sto VS koristi i kao i svaki kompleksan software, postoji ogromna redudancija API-a (rade prakticno istu stvar, preklapaju se u necemu, ili su rewrite tj. nove verzije). Na zalost, ne znam koje je resenje za software- kada code base naraste (meri se u milionima linija koda) plus ogroman legacy (VS recimo i dalje omogucuje prakticno da se otvaraju neki editori iz vreme dinosaursa) jer pre nekoliko godina sam se susreo isto sa code-om gde su se vlasnici hvalili da su dostigli 2 miliona linija code-a (projekat je bio .NET + C++) ali code je bio uzasno loseg kvaliteta i niko u stvari ne zna gde se sta nalazi i sve je jednostavno sporo jer uvek neko nekog ceka (mislim na API, recimo stavim breakpoint i tipa funkcija Initialize, koja po samom imenu kaze da je nesto heavy i treba da se inicializuje samo jednom, u stvari se poziva vise puta od boga pitaj kojeg sve handlera, stack trace je dugacak kao stospratnica, prakticno nemoguce izdebagovati, a da apstrakcija i IoC da tek o tome ne pricam). I tako, mozes da imas masinu ne znam ja koliko jaku, pola code-a niko ne razume, drugu polovinu koju neko razume bazirana je na nekim lock-ovima i nekim timer-ima :)
[ bojan_bozovic @ 31.12.2018. 07:33 ] @
Resenje je softver koji nema nepotrebnu funkcionalnost, no to resenje ne zele kompanije koje su software vendori. O tome je pisano jos pre dvadeset pet, trideset godina, i to su radili daleko pametniji ljudi od mene, ali uzalud. A ni FOSS developeri nisu mnogo bolji, i oni vole da izmisljaju toplu vodu.
[ Branimir Maksimovic @ 31.12.2018. 09:38 ] @
"Mislim moja "radna" masina ima 128 GB RAM-a, 36 jezgara (fizickih) na 3.3 GHz, 1080 Ti grafiku, NVMe SSD-ove - dakle, sve prilicno brz hardver, i onda startujes Visual Studio i on nesto drnda 10-20 sekundi ponekad. Office isto, cesto zaglupi na par sekundi."

Mislim da bi iskustvo bilo isto i sa nekim i3 i 8gb rama :P
[ bojan_bozovic @ 31.12.2018. 09:47 ] @
Ja imam i3 sa 8Gb i svakako da je isto, no sta je alternativa, neki novi OS i userland koji bi bili bez bloat-a? Ako iko ima nameru da se tome problemu posveti, morace da postavi ostvarive ciljeve.
[ Branimir Maksimovic @ 31.12.2018. 10:42 ] @
Znas kako, .NET je doneo veliki bloat u MS realm. Sa obzirom da je to single threaded aplikacija ocigledno jedino sad da dignes na 5Ghz pa malo da ubrzas :P
[ Ivan Dimkovic @ 31.12.2018. 11:23 ] @
Citat:
negyxo
I tako, mozes da imas masinu ne znam ja koliko jaku, pola code-a niko ne razume, drugu polovinu koju neko razume bazirana je na nekim lock-ovima i nekim timer-ima :)


Mislim da je u ovome srz velikog broja problema. Jako puno koda koji sam imao prilike da vidim je zapravo izuzetno los multithreading kod. Mislim da svako ko je iole duze radio kao developer ima slicna iskustva, osim ako bas nije imao srece da radi na projektima koje su radili pravi eksperti.

Mislim ja sam vidjao svasta, od potpunog odsustva ideje da moze doci do race-conditiona i koda koji spava na po 10ms u beskonacnoj petlji u jednom threadu kao subsitucija za tajmer (ovo je bilo cca. pre 15-tak godina, ne znam da li i danas ima takvih nenormalnih konstrukcija), preko "multithreaded" koda koji zapravo provodi vecinu vremena lock-ovan gde gomila thread-ova pokusava bezuspesno da menja isti resurs, do gomile nepotrebnih tajmera i lock-ova koji bi bili eliminsani samo da neko malo bolje razmisli o strukturi podataka i arhitekturi aplikacije.

Ali to kosta, jako puno. Dobri developeri su jako skupi i obicno zele da rade na interesantnim stvarima, tako da za gomilu stvari ostaju prosecni (ako imas srece) ili losi developeri koji ce pisati kod koji postize rezultate ali obicno na neoptimalan nacin. Tu je naravno jos i problem vremena, projektovati i implementirati nesto kako treba zahteva vremena = novca = jako puno novca ako pricamo o kvalitetnim developerima. To ili "kupi brzi PC"? Menadzeri ce obicno izabrati ovo drugo.

Secam se kad se pojavio prvi Pentium 4 sa Hyperhtreading-om, to je bio prvi momenat u konzumerskoj PC industriji da 2 niti zaista mogu da se izvrsavaju u isto vreme (do tada su prakticno niti uvek bile izvrsavane serijski). Nastao je >haos< - userland kod je pucao na sve moguce nacine (posto niko nije debugovao probleme paralelnog izvrsavanja do tada) dok je gomila drajvera BSOD-ovala masinu zbog istih problema, samo u kernel modu.

P4 sa HT-om je naterao developere da na brzinu fixuju kod, u roku od nekoliko godina (cca. sredina 2000-tih) je to manje-vise "sredjeno" u smislu da kod ne krahira / ne daje pogresne rezultate, ali sto se performansi tice vrlo verovatno je gomila tog legacy koda izuzetno daleko od optimalnosti sto se paralelnog izvrsavanja tice. Ne znam koliko je koda iz te ere ostalo u danasnjih velikim aplikacijama, pretpostavljam dosta za mnoge od njih.

Sledeca generacija PC platformi (Nehalem, Sandy Bridge, itd. sve jaci GPU-ovi) su omogucile developerima da se oslanjaju na framework-e koji su masivni, ali hej - koga briga, performanse PC-jeva su skakale i skakale. Tako da danas, u principu, ako developujes za PC client, optimalne performanse su nebitna stvar osim u nekim vrlo specificnim slucajevima gde je to imperativ za aplikaciju (gaming, profesionalni A/V editori, itd.).

IMHO, mislim da su smartphone-i bar u pocetku bili pozitivna stvar zato sto su zahtevali da se bar malo razmislja o implikacijama loseg koda na user experience (baterija, "krzav" UI, itd.), ali danas i mobilni telefoni dozvoljavaju "debele" frameworke i los kod tako sto se OS brine o "uspavljivanju" aplikacija a ogromna kolicina snage dostupne dozvoljava i da los kod radi prihvatljivo dobro za korisnika.
[ Branimir Maksimovic @ 31.12.2018. 12:02 ] @
Ivan:"koda koji spava na po 10ms u beskonacnoj petlji u jednom threadu kao subsitucija za tajmer"

Znas kako timer mozes tako implementirati, potom bacati signal ili ubaciti u event loop. Linux nudi opciju 1. i 2. dok Windows nudi opciju 3.
[ Space Beer @ 31.12.2018. 13:13 ] @
Ja razumem da je program koji se piše godinama i koji ima hiljadu opcija, trom i "težak" za korišćenje. Posebno kada pokušavaju da ga uglave u "moderan" način rada. Mislim da je AutoCAD najbolji primer. Ali ne razumem zašto neko ima želju da razvija od nule npr. program za foto editing ili CAD koji će se oslanjati na chroimum i js da bi bio dostupan iz browsera ili "desktop" aplikacije u electron varijanti? Razumem da je to nekada korisno, ali sam mislio da će zaživeti servisi kao što je rollapp.com koji ti nude korišćenje (skoro) pune verzije aplikatvnog softvera iz browsera. Ja kad nemam pristup svom računaru koristim neki remote-control softver i radim kao da sam tu. Manja je patnja nego rad u npr. Google docs-u.

Ili npr. Onlyoffice. Iz browsera se ponaša isto kao i bilo koji drugi web office paket. Na telefonu takođe. Ali je zato "desktop" varijanta đubre u poređenju sa bilo kojim drugim paketom. I zašto bih onda ja birao taj program, kada mi MS ili LO+Collabora nude bolje rešenje? Ok, razumem kada je nekome dovoljan draw.io i neće da plati Visio, ali npr. yEd ima bolju desktop verziju iako je pisan u Javi :d

Ako je saradnja prioritet, i to se može rešiti na bolji način. Većina cloud provajdera nudi takvu mogućnost, i to rešenje je zaista jednostavno, ako neko ne želi da investira u ozbiljniji data management softver. Šta vuče ljude da se fokusiraju na web, to meni nije jasno? I ako im je već to prioritet, zašto se fokusiraju samo na jednu platfromu - u ovom slučaju Chrome? Tj. zašto develeoperi i menadžeri ne vole svoje kupce :)
[ Branimir Maksimovic @ 31.12.2018. 13:20 ] @
"zašto se fokusiraju samo na jednu platfromu - u ovom slučaju Chrome?"

Iz istog razloga sto su se fokusirali na Javu. Besplatno. Kreses brdo troskova na razvoj svog engine-a. No kako je sad sa Javom od Januara, i Gugle moze da pocne da naplacuje ako u tome vidi profit.
[ Space Beer @ 31.12.2018. 13:48 ] @
Ma kakvi. Najmanji je problem naći besplatan alat, a kada si veliki kao npr. Autodesk, mislim da ni resursi nisu problem. Trenutno oko 20% ljudi koristi non-Chromium browsere. Na 4-5 milijardi, to je ogroman broj (potencijalnih) korisnika. Zašto onda Autodesk ne želi da omogući Firefox, Safari, Edge... korisnicima da koriste njihove servise? I to je samo jedan od primera. A prelaskom Edga na Chromium, biće ih sve više
[ negyxo @ 31.12.2018. 13:50 ] @
Citat:
bojan_bozovic:
Resenje je softver koji nema nepotrebnu funkcionalnost, no to resenje ne zele kompanije koje su software vendori. O tome je pisano jos pre dvadeset pet, trideset godina, i to su radili daleko pametniji ljudi od mene, ali uzalud. A ni FOSS developeri nisu mnogo bolji, i oni vole da izmisljaju toplu vodu.


Pa tesko je da se ne slozi sa ovim ali to je kao da kazes "resenje za korupciju su dobre institucije i postovanje zakona", drugim recima, jasno je da je tako ali tako nesto postici je izuzetno tesko. Sumnjam da firme koje su vlasnici software-a ne zele ovo sto ti kazes ali realnost je drukcija. Skoro svaki software vremenom postane bloatware, retki su primerci gde software vremenom postane bolji i stabilniji, tako da je to vise izuzetak nego pravilo i nebitno je da li je free ili payed, da li je open ili closed, kada code base naraste i ukljuceno je vise ljudi/timova neminovno je da dolazi do degradacije, opet, cast izuzecima, cak sta vise milsim da bi se analizom koliko je ljudi radilo na odredjenom software-u mogla pronaci korelacija o kvalitetu software (sto vise ljudi, losiji rezultat).

Branimir
Citat:

Znas kako, .NET je doneo veliki bloat u MS realm. Sa obzirom da je to single threaded aplikacija ocigledno jedino sad da dignes na 5Ghz pa malo da ubrzas :P


VS je jako kompleksan proizvod da bi ga nazvao single theaded. Recimo language services za C#, Roslyn, je optimizovaniji nego prethodna implementacija (koja mislim da je bila u C++) iz prostog razloga jer jer drukcija organizacija. Prvo, zbog komplektnog API-a koji je otvoren i expose-ovan VS-u, pa samim tim ne radi se naknada analiza code-a zarad intelisense-a i raznih ostalih servisa koji se oslanjaju na sam code (recimo syntax higlihting, suggestions, layout, ekstenzije itd.), drugo, sto je sada paralelizacija na nivou fajla, tj. svaki C# fajl se procesira zasebno na novom thread-u (tj. verovatno su taskovi pa sam scheduler odlucuje kada je optimalno da ide na novi thread). Opet, ovo je samo delic VS-a, postoji mnogo (internih) servisa koji trce od momenta kada se upali VS da je skoro nemoguce trace-ovati ko tacno blokira izvrsavanje.



[ bojan_bozovic @ 31.12.2018. 13:54 ] @
@Space Beer

Iz tog rasloga sto mogu da naplacuju softver kao uslugu - ne placas pretplatu, nema softvera. Da li je bolje vrteti program na cloudu, ili ga vrteti lokalno? Za koga je bolje, za korisnika, ili softver vendora koji to naplacuje?

Slicno mozes da vidis bas svuda. Danas su korisnici razmazeni zele da neko drugi obavi njihov deo posla.
[ Branimir Maksimovic @ 31.12.2018. 13:59 ] @
negyxo:"tj. verovatno su taskovi pa sam scheduler odlucuje kada je optimalno da ide na novi thread"

Ocigledno nije optimalno inace se Ivan ne bi zalio ;p
[ negyxo @ 31.12.2018. 14:22 ] @
Nope, sumnjam da Ivan radi C# projekte :)
[ Branimir Maksimovic @ 31.12.2018. 14:33 ] @
Znaci onda da je za C# mutli inace single, ne? ; )

edit:
inace sad sam na nekom VS projektu, i nepopravljivo kompajlira single threaded. Sa obzirom da imam isustva sa VS jedva 6 meseci u 27 godina kolki mi je staz jel moze
neka dobra dusa da mi pokaze kako da namestim da kompajlira kao make -j recimo?
[ negyxo @ 31.12.2018. 14:59 ] @
Roslyn compiler za C# bi trebalo da je multithreaded, mada po ovom linku, deo je multithreaded dok je parsiranje single threaded, no sada je pitanje sta je sta, kompajler radi dosta stvari i pitanje je sta se na sta odnosi ali secam se pre par godina da je Eric Lippert (covek zaduzen za C# razvoj) pisao na svom blogu bas o tome da je Roslyn file level parallelized. No, bitno drukcija organizacija je kljuc zasto je optimialnije sa Roslynom nego pre (kao sto vec spomenuh, samo na jednom mestu se radi kompajliranje i to je ekposozovano kao language service svim ostalim servisima), no to je sada offsetvano tako sto je dodato brdo novih feature-a na racun toga :)
[ Ivan Dimkovic @ 31.12.2018. 15:37 ] @
Citat:
Branimir Maksimovic:
Ivan:"koda koji spava na po 10ms u beskonacnoj petlji u jednom threadu kao subsitucija za tajmer"

Znas kako timer mozes tako implementirati, potom bacati signal ili ubaciti u event loop. Linux nudi opciju 1. i 2. dok Windows nudi opciju 3.


Ne dovodim u pitanje da tako mozes implementirati tajmer, ali taj kod o kome pricam apsolutno nije imao potrebe da budi thread svakih 10 milisekundi i radi nesto (plus, ostatak tog koda je bio thread-unsafe, ali to je vec druga prica). Cela stvar je mogla biti uradjena asinhrono, sa budjenjem tacno kada treba ali... ko god je pisao taj kod ocigledno nije umeo da uradi to kako treba.

Ili jos sampionskija stvar, Windows je dozvoljavao (ne znam da li i dalje dozvoljava, znam da su smanjili lose efekte prelaskom na tickless) da bilo koja sugava aplikacija poveca rezoluciju Sleep()-a do 1ms - nekada je rezolucija bila izmedju 10 i 15 ms, sto je bio standardni sistemski kvant na NT sistemima (obicno 15 ms).

Kao sto mozes da pogodis, svaki genije koji je "morao da ima preciznost u milisekundama" (pogotovu u samo-izmisljenim "tajmerima") je samo trebao da pozove jednu Win32 API funkciju (bez admin privilegija) i da natera ceo prokleti sistem da poveca rezoluciju tajmer interapta sa 60-100 na 1000 puta u sekundi. Mislim da je cak i Chrome browser to radio. Verovatno su spucani megavati struje zbog takvih idiotizama.

Sve u svemu, odavno smo usli u fazu da je generalno kod djubre i bar neki OS-evi se trude da minimizuju stetu.

Sumnjam da moze ici na bolje od toga.

[ Ivan Dimkovic @ 31.12.2018. 15:52 ] @
Citat:
Branimir Maksimovic:
negyxo:"tj. verovatno su taskovi pa sam scheduler odlucuje kada je optimalno da ide na novi thread"

Ocigledno nije optimalno inace se Ivan ne bi zalio ;p


Ne poznajem arhitekturu Visual Studio-a pa ne mogu da komentarisem da li je optimalna ili ne, samo mogu da primetim da na masini koja je sve samo ne slaba imam situacije da cekam sekundama (nekada i duze) na trivijalne operacije.

Razumem da je to posledica decenija prosirivanja, boga pitaj koliko refaktoringa i cinjenica da je VS izuzetno komplikovan proizvod koji mora da podrzi gomilu ekstenzija, ali to ne opravdava fakat da ti IDE stuca na 36 jezgara i 128 GB RAM-a.

A o tragikomicnim problemima sa vecim projektima koji iz cista mira krecu da se stalno bilduju od nule da ne pricam... ako ikada budem pocinjao neki licni projekat od nule, ima da bude cist makefile :)

Inace, pre mnogo godina i pre Windows-ovih internih alatki za profilisanje Windowsa sam raspisao aplikaciju koja je radila profajling Windows boot-ovanja sa registrovanjem kad se sta desilo (u principu gro aplikacije je bio drajver koji se ucitavao vrlo rano u boot procesu i hook-ovao sta je mogao). Fantasticna stvar koju sam tada naucio je da boot proces uopste nije bio toliko I/O ili CPU opterecen, koliko je vremena prolazilo na inicijalizaciju drajvera. Nisam dublje ulazio u problem (tipa profajling drajvera) ali pretpostavljam da je gomila drajvera verovatno imala neke interne timeout-ove i nisu vracali kontrolu sistemu pre nego sto zavrse sta god su imali da urade.

Secam se da je Microsoft negde oko Viste ili 7-mice (valjda, ne secam se vise) uveo paralelnu inicijalizaciju drajvera upravo kako bi smanjili problem. Ali i dan danas, recimo, meni se OS cold-bootuje jako dugo, iako je na najbrzem konzumerskom NVMe disku i radi na prilicno brzim procesorima. Ali fakat da mora da inicijalizuje brdo hardvera ocigledno jos nije zadovoljavajuce resen.
[ Nedeljko @ 01.01.2019. 20:07 ] @
Ovde se problematizuje monopolizacija tržišta web engine-a cloud eri.

Ja mislim da je cloud u danas masovnom obliku problem, kakav god da se web engine koristi.

Zašto AutoDesk ne podržava druge web engine? Da li mu je 20% korisnika drugih web engine-a problem? Očigledno nije, jer

1. Ima monopol nad CAD segmentom.

2. Korisnik će vrlo lako za AutoCAD da koristi web browser koji mu AutoDesk odredi, bez obzira na to koji web browser koristi za druge stvari.

Zašto se piše neoptimizovan kod? Zato što korisnici ne žele da odreše kesu za optimizovan kod.
[ Branimir Maksimovic @ 02.01.2019. 01:34 ] @
Ivan:"Sve u svemu, odavno smo usli u fazu da je generalno kod djubre i bar neki OS-evi se trude da minimizuju stetu."

Mislim da OS tu ne moze mnogo. Recimo na Windows-u zesci bloat dolazi od antivirusa koji su se ranije (ne znam da li i danas) inkorporirali u kernel.
Vidjao sam kako neki antivirus rusi XP kernel bez problema, a to su programi koji se vrte 24/7 i usporavaju sve operacije.
Iance kvalitet Windows koda sudeci po headerima is visual studia i samom WinApi-ju je questionable...



[ Ivan Dimkovic @ 02.01.2019. 19:35 ] @
Slazem se, zapravo nisam ni mislio na Windows vec na iOS i, u nekoj meri, Android. Windows je verovatno bez nade zbog kompatibilnosti koju moraju da odrzavaju.

Moje misljenje o Windows antivirusima (ne znam kako funkcionisu na drugim OS-evima) je vrlo nisko, to sta se dozvoljava tim aplikacijama je prakticno isto sto rade i virusi (u smislu niske "integracije" u OS) samo se AV vendorima veruje da ne rade nista lose.

Citat:
Branimir Maksimovic
Iance kvalitet Windows koda sudeci po headerima is visual studia i samom WinApi-ju je questionable...


Ako pogledas npr. Windows Research Kernel, videces da je kernel kod Windowsa dobrog kvaliteta i vrlo cist.

Userland kod... ko ce ga znati, verovatno druga prica :-)
[ Branimir Maksimovic @ 03.01.2019. 01:38 ] @
Ma mene nervira sto prebacuju sve preko integera (wparam,lparam) sto automatski elimininise arhitekture koje imaju sire pointere. I potom nema mogucnosti prebacivanja user data pa ne mozes this pointer
da prebacujes u window proc tako lako. Ja sam pravio run time generaciju thunka samo da bih mogao da prosledim this pointer ;p

edit:
a da ne govorim sto je lik ogranicio 32 bitni proces na 2GB zato sto je uzeo jedan bit da razlikuje pointer od handle-a ;)

[Ovu poruku je menjao Branimir Maksimovic dana 03.01.2019. u 02:55 GMT+1]
[ bojan_bozovic @ 03.01.2019. 08:40 ] @
Branimir Maksimovic

To je API iz vremena kad je 8 Mb RAM bilo dovoljno za skoro sve. Zasto ne koristis 64 bita? Zasto uopste maris za 32 bita u 2019. jer ko uopste prodaje 32 bitne racunare?
[ Ivan Dimkovic @ 03.01.2019. 10:17 ] @
Citat:
Branimir Maksimovic:
Ma mene nervira sto prebacuju sve preko integera (wparam,lparam) sto automatski elimininise arhitekture koje imaju sire pointere. I potom nema mogucnosti prebacivanja user data pa ne mozes this pointer
da prebacujes u window proc tako lako. Ja sam pravio run time generaciju thunka samo da bih mogao da prosledim this pointer ;p

edit:
a da ne govorim sto je lik ogranicio 32 bitni proces na 2GB zato sto je uzeo jedan bit da razlikuje pointer od handle-a ;)

[Ovu poruku je menjao Branimir Maksimovic dana 03.01.2019. u 02:55 GMT+1]


Win32 API je zbrda-zdola zbudzena ekstenzija Windows 3.x API-ja zbog odrzavanja maksimalne kompatibilnosti i od tog momenta je evolucija istog bila zakucana sa tim.

Sama imena (wparam, lparam) su relikti te istorije i cinjenice da je Windows API originalno nastao na 16-bitnoj PC arhitekturi.

Sa druge strane, kernel deo NT familije Windows-a (NT, Win2k, XP, Vista, 7/8/10) je od starta bio propisno dizajniran zato sto ga je radio kompetentan tim neobuzdan sa odrzavanjem kompatibilnosti. Originalno je NT API trebao da ima OS/2 API kao userland ali je zbog izuzetnog uspeha Windows-a cela stvar promenjena i tako je i nastao "Win32 API".

Na zalost po performanse i kvalitet, MS je uvek prioritizirao maksimalnu kompatibilnost i njihove userland API odluke su takve kakve jesu zbog toga.

Btw, tvoj problem sa this pointerom o kojoj se arhitekturi radi?

64-bitni Windows API ima SetWindowLongPtr API koji prima LONG_PTR kao argument, tako da mozes da stavis 64-bitni pointer kao GWLP_USERDATA na sta god hoces.
[ Branimir Maksimovic @ 03.01.2019. 11:01 ] @
Znas kako problem je u tome 'set'. Znaci da bilo sta u bilo kom trenutku moze da nasetuje pointer na nesto drugo i eto problema ;(
Pazi nisam se dzabe mucio da generisem thunk gde this pointer bacam kao prvi argument u member f-ju / windows proceduru koji pozivam ;p
[ Ivan Dimkovic @ 03.01.2019. 11:10 ] @
Hmmm, priznajem da je moje znanje Windows API-ja matoro, ali CreateWindow prima lpParam koji je LPVOID, tj. sirine pointera na radnoj arhitekturi.

Taj parameter ce biti prosledjen tvojoj Window proceduri u WM_CREATE poruci i onda ti mozes unutar obrade te poruke da je uskladistis gde god hoces, ako ne verujes Windows API-ju tj. bojis se da neko drugi moze da ti pokvari GWLP_USERDATA podatke od prozora, onda mozes da napravis neki svoj niz (hwnd, this ptr.) kojem samo ti imas pristup.

Ali Windows API ti daje mogucnost skladistenja 64-bitnih podataka u njihovoj internoj strukturi prozora - posto je to C API, nemas "privatnost" (kao sto si primetio) ali to je muka sa celim Win32 API-jem uopste, unutar procesa se smatra da su svi "fer plejeri" :-)

Bilo je gore nekada, nekada si cak mogao izmedju procesa da "kvaris" prozore, secam se da je u vreme Windows 95-tice to bio jako popularan sport "unapredjenja" prozora sa kojekakvim nakaradnim subclass-ingom / hook-ovanjem. Srecom pa su kasnije uveli restrikcije da se gomila stvari moze promeniti samo unutar istog procesa. To je jos jedan "hint" koji otkriva pravo poreklo Win32 API-ja - sa single-user, nesigurne 16-bitne platforme gde se sve "delilo" kao u jednoj velikoj srecnoj familiji :-)
[ Branimir Maksimovic @ 03.01.2019. 11:18 ] @
Pazi nije mi bilo tesko da odmah naidjem na ovo:
Citat:

While using the SetWindowLongPtr and GetWindowLongPtr to access the GWL_USERDATA might sound like a good idea, I would strongly recommend not using this approach.

This is the exactly the approached used by the Zeus editor and in recent years it has caused nothing but pain.

I think what happens is third party windows messages are sent to Zeus that also have their GWL_USERDATA value set. One application in particular was a Microsoft tool that provied an alternative way to enter Asian characters in any windows application (i.e. some sort of software keyboard utility).

The problem is Zeus always assumes the GWL_USERDATA data was set by it and tries to use the data as a this pointer, which then results in a crash

https://stackoverflow.com/ques...his-pointer-for-use-in-wndproc

A gle ovo na istom:
Citat:

ATL's thunk is the most efficent. the thunk executes once and replaces the callback function for the WINPROC to the classes own message processing member function. subsiquent messages are passed by a direct call to the classes member function by windows. it doesnt get any faster than that.


Znaci radio sam isto sto radi ATL ;)
[ Ivan Dimkovic @ 03.01.2019. 11:32 ] @
Uprvo - problem je sto "privatni" podaci nizu zaista privatni posto u Win32 API-ju i dan danas do neke mere (mnogo manje nego ranije) 3rd party moze da ti "ukrasi" prozor sa svojim hook-ovima / promenama i unese probleme ako se oslanjas da su podaci koje si setovao u HWND strukturi zaista tvoji.

Zato se slazem da je bolje da svoje privatne podatke drzis razdvojeno od HWND "privatnih" podataka i da ih nalazis po HWND kljucu ili kako vec hoces. To sto stavis u HWND podatke je za ceo svet da vidi i, ako imaju dovoljno privilegija, i da menjaju.
[ Space Beer @ 19.01.2019. 17:49 ] @
Evo i Igor ima nešto da kaže na ovu temu, manje-više :)
https://www.dedoimedo.com/comp...ge-for-the-sake-of-change.html

Jedino se ne slažem da je kod avio-prevoznika problem low-cost ponuda i loša usluga, pošto uvek postoji biznis pa i prva klasa :) Veći problem su ovakve situacije, nastale iz istog razloga kao i sve ostalo što je naveo
https://www.bleepingcomputer.c...cted-by-major-security-breach/
[ mmix @ 18.02.2019. 17:05 ] @
Malo je zamrla tema. Samo da dodam da je VS spor zato sto je 32bitno go*no koje je vecito memory-starved.

Problem sa MSom je sto rapidno gubi competency za low level stvari, oni su defakto postali service delivery kompanija i samim tim se .NET vec godinama puni apstraktnim ignoramusima. Njihove price i izgovori su sve smesniji, proizvodi sve nestabilniji i sve blizi teletabisima. Ja realno ocekujem da ce oni jednog trenutka napraviti disconnect sa Windowsom i da ces moci samo da iznajmis (ne kupis) Windows u S rezimu, gde ces moci da rentas (ne kupis) office alate u UWP/O365 izdanju.

[ bojan_bozovic @ 18.02.2019. 17:08 ] @
Nece. Windows je mnogo vise, i embedded, i gaming, i server nisu ludi da to urade.
[ Branimir Maksimovic @ 18.02.2019. 17:50 ] @
Citat:
Malo je zamrla tema. Samo da dodam da je VS spor zato sto je 32bitno go*no koje je vecito memory-starved.


Hahhaha. Mora da su zato izbacili inline asembler iz 64 bitnog kompajlera ;p
[ mmix @ 18.02.2019. 18:32 ] @
Nista to njima ne znaci jer im ne donosi nikakav revenue. U server domenu rapidno gube market share svejedno, na deskotpu caruju ali su uspeli da sebi potpuno ubiju revenue sa "Windows 10 je poslednji Windows" politikom, nema novih windowsa == nema buducih prihoda od upgrade licenci. Nutela ne ume da razmislja na tom perpetual licencnom modelu, on je full blown rent-a-lik.

Ljudi koji rade u MSu a sa kojima pricam su svi u HTML/CSS fazonu, igraju se, portuju stvari na UWP i, jos grdje, Electron (sa kojeg posle moze lakse da se portuje na Azure). Nema od njih vise nista ozbiljno sto se tice desktopa. Sve sto .NET radi vec par godina je Azure up-selling.


Sto se tice gaminga, njih to ponajmanje zabole, ako nisi primetio DX13 ne postoji ni u uvijenoj najavi, sve sto se desilo u poslednjih x gdina je da je dodato ray tracing support zbog Nvidia-e. Oni su u full-on modu kanibalizacije desktopa. Ako ubiju PC gaming njima to nista ne znaci, sta vise moze samo da im bude plus jer ce deo gejmera preci na Xbox. isto vazi i za desktop aplikacije. Neko ce da predje na Linux zbog toga? Bas njih briga, ti ljudi im ionako nisu izvor prihoda. Ako predjes na Linux zbog Steam/Proton-a, svejedno ce ti trebati Office za druge stvari => O365 cha-ching.

Embedded Win je mrtav. Ivan moze vise da ti prica o auto-industriji, mozda je tamo drugacije, ali sto se tice house appliances, tipa set top boxova Win je mrtav, mi sad npr sve nove settop boxove za IPTV dobijamo na Linuxu. ATMovi novi su svi na Linuxu. Microsoftovoa IoT ponuda je naravno cloud based, jer tu lezi buduci revenue.

Zivi bili pa videli, Windows kakav sad imas dozivljava poslednje dane, Nutela je cvrsto resio da ode full-retard u Apple poslovni model u dubine o kojima Steve Jobs nije ni razmisljao. Oni full blown hoce da ti kupis XXX dolara vradan hardver da bi na njemu vrteo browser i browser based aplikacije jer drugu opciju nemas.
[ Branimir Maksimovic @ 18.02.2019. 18:36 ] @
"Oni full blown hoce da ti kupis XXX dolara vradan hardver da bi na njemu vrteo browser i browser based aplikacije jer drugu opciju nemas. "

Gledano kako se kupuje bice da je tih xxx dolara, sada negde oko 100...
[ mmix @ 18.02.2019. 19:03 ] @
Ne bas vecinski, ali u rangu 300 koliko kostaju konzole. A opet i ti sa 100 dolara masinama mogu da konzumiraju njehov service delivery program za 5-20 dolara mesecno jer njihov appdev filozofija je iOS na desktopu, pardon UWP na desktopu. Sitna para uz veliki obrt => velika para. Na UWP pride iskesiraju 30% od svakog dolara koji devovi naprave.

Sasvim sigurno novi Windows mentalitet nije za gaming rigove od 2000e. Za Nutelu, ljudi sa tim masinama su na nivou statisticke greske i prihod od njih je mizeran. Oni ima nulti pride u svoj postojeci proizvodni program koji je nasledio, 97% market share na desktopu mu ne znaci nista ako nije preveden u konstantan priliv kinte i kanibalizovace ga bez problema za 20% proboja na service delivery. Za njega je cela ta prica sa backward kompatibilnoscu samo uzasavajuci smor koji mora da trpi jer jos nije spreman da ga odbaci. A rapidno se ide ka tome.

[ bojan_bozovic @ 18.02.2019. 19:09 ] @
@mmix

Pa PC se razvija samo zbog gaminga, inace i neki petnaest godina stari kompjuter bi trebao da bude dovoljan za osnovne potrebe. Ja stvarno ne znam Radeon Vega 64/nVidia 2080 Ti/i9/Threadripper to li je za Youtube, Facebook i Office?
[ mmix @ 18.02.2019. 19:35 ] @
Nista ti ne bi video od tog razvoja da nema minera, ali dobro to je druga prica.


Ova prica je da njih zabole za to. Zabole ih i za razvoj PCa. Oni ne prave PCeve tog kalibra (Surface tesko da je gaming PC), ako ce 15-godina star PC da potera Win10 S i da omoguci prodaju O365 paketa, fenomenalno za njih.
Nece oni odmah krenuti sa full blown UWP modelom, bice verovatno Steam preko Marketplace-a uz neki extortion dil sa Gabeom oko podele kinte koju otimaju game devovima u zamenu za runtime privileges na DX-u. Sta mislis sto debeli Gabe grebe rukama, nogama i noktima za Proton? Zato sto voli Linux? Ne, nego zato sto je prvalio da ce ga Nutela pozicionirati izmedju cekica i nakovnja i zeli da bar deo svog marketa prebaci na Linux da moze da nastavi da uzima svojih 30%.
Ti ces naravno moci da ostanes na Windowsu kao gejmer bar jos neko vreme, Nutela ce ti rado rentati Windows 10 Home za, ja pretpostavljam, 6-8$ mesecno, uz konverziju perpetualne licence u prvih 6-9 meseci besplatne rente. Dobar deo gejmera ce ostati, ja i meni slicni cemo preci na Linux, njemu i dalje super.
[ Space Beer @ 24.02.2019. 06:04 ] @
Dobar PC nije potreban samo za gejming, već i za razvoj softvera, inženjerkse programe, foto, audio i video obradu... Ali i to se sve više seli u oblake. Tako da je scenario u kom ćemo iznajmljivati sve te programe i koristiti ih na hardveru koji je u rangu nekog Celerona, sasvim realan. Jedino što može usporiti taj proces jeste zabrinutost (ozibljnih) korisnika što zavise od tuđeg računara.

Evo još jedne varijante za brzi razvoj "PC softvera". Ne znam da li je bolje ili lošije rešenje od Electrona, ali mi se podjednako ne sviđa.
https://www.phoronix.com/scan....p;px=HTML5-Golang-Desktop-Apps

A imamo i ovo
https://www.macrumors.com/2019...l-apps-ios-mac-coming-by-2021/

Umesto da korisnici imaju dva tipa proizvoda, svaki optimizovan za određenu upotrebu, imaćemo dva tipa proizvoda od kojih nijedan ne radi svoj posao kako bi trebalo

Propasti nećemo, al' spasa nam nema :d

[Ovu poruku je menjao Space Beer dana 24.02.2019. u 07:22 GMT+1]
[ bojan_bozovic @ 24.02.2019. 08:35 ] @
Problem sa firmama a i programerima je sto hoce brz development, samo nesto na brzinu da se odradi, a sta ne platis na mostu platis na cupriji, u vidu security exploita. A to je potpuno pogresan pristup.
[ Branimir Maksimovic @ 24.02.2019. 09:06 ] @
Cloud == insecure. Stto se tice electrona-a i ovog sa html5+golang, pa svakako da ce raditi bolje nego JS ;p u svakom slucaju koristiti browser kao UI za desktop aplikacije je mozda ok ideja. Vidim da su i VSCode i Atom radjeni sa electronom.
Jeste bloatware ali hardware je prejak i za to.
[ Nedeljko @ 24.02.2019. 12:11 ] @
Cloud takođe može biti slobodan softver i da se vrti na tvojim serverima, ako se tako plasira.

Recimo, Gitab je zatvoren vlasnički softver, ali se može licencirati za instalaciju na svojim serverima.
[ bojan_bozovic @ 24.02.2019. 12:22 ] @
Nedeljko

Sto ne znaci da je secure, jer i sama komunikacija moze biti inkriminisuca, recimo, ako se skida piraterija sa necijeg sajta ili Google Drive kad vec o cloudu pricamo, ili zaobilazi cenzura kakvu neke zemlje imaju blokirajuci sajtove, to je vec krsenje zakona. Eto taj primer sa piraterijom je dobar primer, da je piraterija lokalno niko ne bi mogao ni da dokaze da preuzimas. Zato je cloud problematican, i ne moze striktno da se smatra bezbednim, vec samo dovoljno bezbedan, mozda, za odredjenu primenu. Industrijsku spijunazu da ne spominjem, tim pre sto i neke drzave otvoreno spijuniraju u korist svojih ekonomskih interesa.
[ Nedeljko @ 24.02.2019. 17:07 ] @
Citat:
bojan_bozovic: ako se skida piraterija sa necijeg sajta ili Google Drive kad vec o cloudu pricamo

To nije cloud na tvojim serverima, nego na nečijem sajtu (hostovanom na serverima koji nisu tvoji) ili na Google Drive-u (Google-ovi serveri).