x86 ir vairak instrukciju ka RISC lidz ar to visparigi atraks RISC procesori ir atraki vienkarshiem uzdevumiem tas atrums galvenokart nak not software (piemeram Photoshop 4GB bet optimizetaka alternativa versija 0.5GB) bija kkas ar mobilo telefonu benchmark detektoriem kas maksligi uzlaboja performanci

kaut ko baigi specifisku dari, lai tas resurss būtu vajadzīgs? 7700 jau vel, pēc idejas, ilgu laiku skries kā kaķis ar terpentīnu zem astes.

Emmm..nu tik cik uzticies laika ziņām.. 🤣

Pirms pāris dienām kā reiz uzzināju, ka par pusotru tūkstoti nopērkami windows laptopi ar arm proci, kas pēc benchmarkiem uzrāda 3-5x labākus rezultātus par manējo i7 7700hq. Varbūt nākamgad oktobrī jāmigrē 😆

https://www.microsoft.com/en-us/windows/end-of-support?OCID=win10_app_omc_win_ie&r=1

Pirms pāris dienām uzinstalēju to "112 Latvija" aplikāciju. Tikko saņēmu pirmo notifikāciju:   Nēnu nav jau slikti pabrīdināt par tādām lietām, ja tam tā aplikācija paredzēta, bet kāda jēga to darīt "post factum"?   Un kā lai šādiem uzticās?

Ir.   Izslēdzu TV - izslēdzas viss, Nokia 8000, resiveris. Ieslēdzu uz resivera Nokia8000 ieeju - tas verķis ieslēdzas. Ar N8000 pulti skaļumu resiverim var regulēt. Ar to man pietiek.

Ir jau visādi projekti.   Kādreiz strādāju pie sistēmas, kur dažādos metro/būvlaikumos utt mēra trokšņu/vibrācijas līmeņus reālajā laikā. Tas viss tiek sūtīts uz serveriem, kalkulēts, vizualizēts utt uzreiz. Ja kautkas aiziet greizi, tad klienti jau saņēmuši notifikācijas, viņu serveri veikuši kautkādas darbības utt. Kautkāda beckupu atgriežāna, tik visu vēl vairāk sajauktu. Ja kautkas saiet greizi, tad reizēm diezgan sarežģiti 'salabot' un pat ar vienu dienu nepietiek lai 'atpiņķerētu' sekas. Vai vispār neviens nedēļu neievēro, ka kautkas cits neiet vai kalkulē ko nepareizi, ši upgreida pēc.

Pricedrop 70 eur

Tādēļ, ka sistēma pēc būtības nav izolēta, atomāra vienība? Tādēļ, ka problēmas reizēm atrod nevis apgreida laikā, bet kādu brīdi pēc apgreida pabeogšanas? Iemesli jau var būt dažādi.   Mūsu gadījumā "menedžeri" arī visos apgreidos piedalījās un procesa laikā arī varēja pieņemt lēmumus, kas attiecās uz biznesu.

Stulbs jautājums, bet kāpēc jālaiž dati no sistēmas, kas nav vēl pacelta? Ja tas ir ar downtime, tad norubī visu, ko var norubīt. Ja bez downtime, tad nu jā, cits stāsts. Feisbuku tiešām neesmu menedžējis. Toties esmu redzējis kā notiek projektu piegādes citos globālos uzņēmumos, nu, stress tur ir, bet contingency plāni arī. Nebūtu jāgaida uz meņeģeri līdz pirmdienai, jo meņeģeri visu laiku pieejami.

Nu tak mutes un mēles ir visiem. Ko tad tu domā kāds 24+ stundas pavadīs kautko labojot? Pienāks rīts un visi būs prom. Ja man kāds prasītu pa nakti kautko 'upgreidot' un pēctam vēl nākamajā dienā palikt uz vietas un turpināt, tad nu sorry, neesu nekāds robots. It īpaši ja ir citi cilvēki, kas var turpināt. Pēc definīcijas jau ja kāds piekrīt strādāt pa nakti, tad vismaz 2 brīvdienas pēctam 😂

Un kādus jēdzīgus lēmumus var sagaidīt no tiem, kam nav ne jausmas, kas un kāpēc nogāja greizi? Tas, kurš naktī bija klāt, varbūt tai problēmai jau stundu, divas veltīja un varbūt pat jau zina risinājumu, kamēr tas, kurš nebija klāt, neko vairāk par "kaut kas nestrādā" nezina un nemaz nevar zināt.

Svaigā galva domāta, ka atnāk tie kas pa nakti tur nemaz nebij. (jo kādus jēdzīgus lēmumus tu vari sagaidīt no tiem, kas bij iespējams augšā visu dienu un nakti, tur var sagaidīt vēl vairāk problēmas)

Nu es uz šito visu nemācēšu atbildēt. Nav nekādas pieredzes ar mūsdienu šāda veida iekārtām (kā jau iepriekš rakstīju: man bija WDTV) un nav arī bijis laika baigi smalki visu izpētīt. Pagaidām tikai parliecinājos, ka viss man vajadzīgais strādā.

Nu sistēmas ir dažādas. Tā pati pacelšana no backupa var būt neiespējama. Nu ko tu "pacelsi", ja jaunās sistēmas dati jau skraida pa ārējām sistēmām? Ko pacelsi no apgreida, ja sistēms "salauztā" sistēmas daļa savu darbu dara nevis katru sekundi, bet reizi mēnesī, nedēļu pēc apgreida?   Potenciālās problēmas apgreida laikā var būt neparedzamas. Vēl foršāk - principā pat bez jebkādiem apgreidiem jebkurā brīdī var iestāties kaut kāda šaize, kas testa vidē ar daudziem terrabaitiem datu nav bijusi atklāta. Ne tur visu paredzēt var, nedz arī "iepriekš saskaņot ar biznesu".   Ja reiz ir paredzēts, ka apgreida laikā var rasties kāda konkrēta (paredzama) problēma, tad pirms apgreida to atrisina vai izplāno, kā to risināt apgreida laikā. Pēc būtības tas nozīmē, ka tā vairs nav "problēma apgreida laikā", bet pilnīgi normāla apgreida procesa daļa.   Runājot par to svaigo galvu piektdienas rītā pēc apgreida… Esmu piedalījies apgreidā, kurš sākās kaut kad pievakarē (ap pl.21, pl.22) un beidzās no rīta, ap pl7., pl.8. Man kā developerim bija nevis aktīvi jāpiedalās, bet jāpaseko līdzi, lai nesavāra pārāk lielas ziepes, un problēmu gadījumā jānokonsultē vai jādebago un jāatrisina problēmas, kas procesā varētu rasties. Gulēt nedrīkstēja, bija jābūt klāt, lai jebkurā brīdī varētu pateikt "pagaidi, pārbaudīšu šito, pēc tam varēsi turpināt" vai atbildēt uz jautājumiem. Par kādu svaigu galvu piektdienas rītā pēc tāda procesa var būt runa? A ja nu apgreidam jānotiek konkrētā datumā? Un apgreida pārcelšana nozīmē, ka apgreids būs iespējams ne agrāk kā pēc 3 mēnešiem (ja paveiksies), bet funkcionalitāti vajag "šeit un tagad"?   Tie scenāriji ir daudzi un dažādi… Neviens no tiem nav ne ideāls, ne "vienīgais pareizais".   Jau sākās - "strādā, *ja* izpildās šāds, tāds un vēl kaut kāds nosacījums".   Saku tak, ka nestrādā variants "visiem lēmumiem jābūt saskaņotiem ar tiem, kas var tos pieņemt, jau iepriekš [neatkarīgi no sistēmas]".  

Jaa. Shie ir paarbaudiiti kanaali. https://youtube.com/@5.1musicchannel https://youtube.com/@surround2821  

Arī lielā sistēmā tam kokam ir jābūt skaidram un procedūrai aprakstītai. Īpaši tāpēc, ka kļūda var izmaksāt miljardus. Nu nevar gaidīt nākamās darba dienas rītu, paņemt pa ceļam kapiju, un gaitenī satiktam kolēģim pateikt - ā, hei, mums tur šaizīte, davaj, ieliekam uz 1iem mītiņu, ja priekšniekam brīvs.

Strādā, ja sīka sistēma un visu var izdomāt un paredzēt.

Tas tā nestrādā.