Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Tuxik

Stran: 1 ... 22 23 [24] 25 26 ... 99
346
Server / Re:HW nároky malých aplikací
« kdy: 02. 03. 2017, 12:01:34 »
A s cim mas presne problem ? Je to naddimenzovane, load CPU nula, RAM tez, takze zadny problem. Proc to je naddimenzovane, tezko rict, ale je to celkem bezna praxe :) A navic zadna ultra konfigurace to neni. Radove pronajem takoveho virtualu za cenu 2-3 hodin programatora, v tom vazne problem nevidim.

HW je opravdu proti lidske praci velmi levny.
S čím mám problém? No s CPU ani ne, tam je mi to jedno, když to není vytížený. U RAM nastává potencionální problém, protože každej stroj dříve nebo později celou paměť sežere na cache. Ono se říká, že paměť je levná, ale:
- 128GB moduly opravdu levný nejsou
- fyzický stroj má omezený maximální množství paměti
- jeden fyzický stroj stojí jak hodně pěkný auto, špička už se blíží cenou k bytu až baráku
- každý fyzický stroj jsou desítky tisíc jen na energiích za rok, další energie jde na klimu, je potřeba mít dostatečně dimenzovaný záložní napájení atd

Ono se to může zdát jako sranda, ale provozovat spoustu flákajících se strojů, kterým stojí procesory a mají narvaný RAMky z velké části zbytečnou cache, to už taková sranda není.

A pronájem? No naštěstí ne každej je takovej čmoudofil a ne každej chce mít svoje data poházený kdoví kde.

Ono nejde o to, že je jeden takovejhle naddimenzovanej virtuál. Ono jde o to, že to je dneska zcela běžný požadavek každé firmy na jakoukoliv kravinu. A když už je ten požadavek na podobný kraviny několikátý jen za letošní rok, tak už začínám mít opravdu na podobný debility alergii.
Kdyby se raději ty zbytečný investice narvali do vzdělávání vývojářů, kteří by potom začali opravdu něco tvořit a ne jen malovat nenažranosti ve frejmvórcích, to by bylo krásně na světě, co?

347
Server / Re:HW nároky malých aplikací
« kdy: 02. 03. 2017, 09:32:18 »
A jistě, že je to htop .

348
Server / Re:HW nároky malých aplikací
« kdy: 02. 03. 2017, 09:31:05 »
Moment, já myslel, že na statický stránky je cache.

Posledně, co jsem měl co do činění s webem, jsme to dělali tak, že se obsah dělal dynamicky pro přihlášený, jinak první anonymní návštěva po změněně stránky vygenerovala HTMLko na disk dokud se nezměnilo, rozesílalo se všem nepřihlášeným. Zátěž CPU klesla na 15%, spotřeba paměti na 20%.
Nene... na statický stránky musí na serveru běžet nějakej java supr čupr frejmwork, klientovi ten java bastl pošle obří javascript, zásadně se odesílá NOCACHE, a čím víc blikátek, tím víc kůůůůůl.... To všechno ti spíchne nějaká firma za pouhých pár mega, takže potom vlastně není důvod řešit, kolik stojí HW. Co na tom, že ve výsledku by to zvládla líp libovolná sekretářka ve wordu, která by prostě uložila dokument se svojí skvělou představou o webu jako html a bylo by.

349
Server / Re:HW nároky malých aplikací
« kdy: 02. 03. 2017, 08:59:01 »

No sorry jako... takhle to dopadá... několik kontejnerů, databáze, java a prd z toho. Několik v podstatě statických webových stránek... Ono mě to zase tak netrápí, běží to na virtuálu, CPU to nežere, volné RAMky jsou mraky... ale tohle jsou MINIMÁLNÍ POŽADAVKY!!! od těch bastlířů. A to chtěli fyzický stroj, že na virtuálu můžou být problémy... smutný, co?

350
Jde o web http://prottapp.com. Tato webová aplikace používá klávesové zkratky pro editaci prototypů. Nemá jich moc. Jsou zde zkratky, které nepoužívjí CTRL klávesu (např. BACKSPACE, MEZERA, ESC). Tyto zkratky fungují dobře. Ale jakmile se objeví zkratka, která obsahuje CTRL (napřiklad CTRL+C, CTRL+V, CTRL+G, CTRL+BACKPSACE etc.), tak to nefunguje. Na widlich to jede, na MacOS X to určitě taky funguje, ale na Linuxu to prostě nefunguje.

Kus kódu nemohu ukázat, neboť tu aplikaci neprogramuji.
Tak tady vznikají ty frikulínský webový sračky, jo? A za tohle chtějí peníze? Jestli jim za to platíš, tak to reklamuj.

351
Server / HW nároky malých aplikací
« kdy: 02. 03. 2017, 06:37:34 »
Ahoj,
nějak mi to už nedá a musím se zeptat na vaši zkušenost. Poslední dobou je v módě na jakoukoliv blbost požadovat server 4 až 8 jader s 8 až 16 GB paměti. Většinou samozřejmě pro různé webíky v různých super frameworcích. Občas se tak řeší i "statické" stránky, které by šlo bez problémů napsat čistě v HTML5 a provozovat klidně na RPi.
Občas je to možná přehnanými požadavky managerů, kteří mají představu, že na jejich stránky budou přistupovat stovky lidí současně - většinou se pak jedná o stovky lidí za rok a z toho je třetina z firmy, třetina od vývojářů, třetina boti a na reálné návštěvy se nedostane.
Nebo mi uniká nějaká nová IT soutěž s tématem "vyžebrej co největší dělo na co největší kravinu"?

352
@jpu: Se ted bavim s MS SW. Potrebuju zmemnsit oddil a ten Disk Manager asi psal nejaky dvojity gnius. Kliknu, reknu Shrink: "Querrying volume for shrinkable place". Nakonec za 5 minut naskoci dialog, nacvakam cislo, odeslu: "Parametr incorrect" a ta sracka se zavre a smytec. Tak znovu: kliknu, reknu Shrink: "Querrying volume for shrinkable place" a zase 5 minut v zadeki. Opravdu, MS SW je nejlepsi.
Já o víkendu přeinstalovával NB jednomu příbuznýmu (pro cizí už na to kašlu), protože po několika měsících přišel na to, že W10 fakt ne... Bohužel teda na W7, bo dělá v ACADu... super, celou sobotu sem se ten krám snažil ukecat, že ovladače stažený ze stránek HP pro W7 jsou opravdu ty správný, poté následovala instalace aktualizací... super... kupodivu jsem chytil záhadný okno, kdy zrovna widloupdate fungoval, takže to trvalo asi jenom 6 hodin, s asi 8 restartama, kdy se vždy po restartu záhadně objevily nový aktualizace, který tam předtím nebyly.... Když se to konečně všechno nainstalovalo, tak jsem v neděli s dobrým pocitem, že je 0 dostupných aktualizací začal instalovat další SW. Odskočím si na oběd a na monitoru hláška instaluji aktualizace 1 z 16??? WTF? Absolutní nezájem o to, že to zrovna kopírovalo skoro 700GB dat z externího disku, prostě to v půlce utnul a začal se aktualizovat.... labůžo... Normálně jsem v pondělí myslel, že ani nepojedu do práce, jaký jsem měl myšokřeče v zápěstí, protože držet volant byl fakt hnus...

353
ono by bolo celkom zaujimave zistenie, aku velku korporaciu ste spravovali, resp. v akej. Tipujem nejake malicky firmicky, ktore ficia a ficali na unixoch.
:D sap, oracle, mssql, desítky fyzických strojů, stovky virtuálních, widle, linux, unix, HA i HP clustery, několik tisíc uživatelů, několik PB úložiště celkem... ano, taková IT drobotina :D

354
No jo, nikto nechce MS, cela firma je podvod, produkty od nich su shit, ale kazdy ich pouziva a plati za to :D
Smutný co? :( A potom jsou plný fóra chudáků "co dělají do ájtý" a stěžujou si, že za neustálé přeinstalovávání woken (protože s nima nic jinýho neumí), berou jenom 15k. Většina jich skončí už při pohledu na windowsí server, nějakej Linux je zcela za hranicí jejich chápání a když do hry vstoupí HP-UX, Solaris, k tomu nějaký sanky, to všechno v nějakým opravdovým clusteru, tak se jdou oběsit.

355
Čmoud je náhodou bezva :D Jde ruku v ruce s dalšími buzzwords jako škálovatelnost, cluster, a podobně. A v této oblasti MS vyniká úúúúúplně nejvíc... svojí neschopností :D

356
Třeba takové čistě OSS nekomerční projekty, jako Oracle, nebo SAP, ty Linux podporují... a SAP HANA dokonce nic jinýho... hmhmhmmmmm to jsou věci po dvou deci... Asi neví, co dělají, chudáci :(

357
Tak ja teda neviem. Ma par kilovy kernel linuxu viac chyb, ako niekolko gigabitovy windows 10, alebo nema? Mam verit doveryhodnym statistikam, ktore sa tym zaoberaju, alebo verit par ostrielancom na roote?  ???
Věř si čemu chceš :D Jen tě upozorňuji, že jádro pro x86 desktop rozhodně nebude mít pár kilo a to "pár kilový" jádro osekaný na kost pro embeded zase nebude mít víc chyb jak windows. Dalším problémem tvého srovnání bude obsah "nepodstatných věcí" v těch Windows... ostatně bylo by zajímavý zjistit, kolik mají W opravdu binárního kódu a kolik z těch několika giga jsou obrázky, ikonky, licenční smlouvy, zvuky atd...

Jen tak pro hrubou představu...

vmlinuz 7,3M
iwlwifi.ko 263K
iwldvm.ko 185K
iwlmvm.ko 340K

Tohle je moje jádro + moduly, silně osekaný na konkrétní HW tak, aby mi nic nechybělo k pohodlnému životu. Celkem by mě zajímalo, jak je na tom třeba nějaký *buntu.

358
Zdejší diskutéři léta tvrdili, že Widows mají vyšší počty chyb, protože jsou mizerně napsané a Linux (který se tehdy používal výrazně méně než dnes) je prostě lépe napsaný. Teď se situace obrátila a Linux má zranitelností daleko více, takže pro změnu tvrdí že jsou Windows mizerně napsané, a v Linuxu se chyby jen lépe hledají. Přijde mi to jako pokrytectví. Já na to mám ten názor, že jak se Linux začal více používat, tak začalo mít finanční smysl v něm hledat bugy, a navíc se s časem zvyšuje jeho složitost, takže je těch bugů více.
Ono by taky bylo potřeba přihlédnout k dalším věcem, například jen velmi malé procento kritických chyb v Linuxu je zneužitelné globálně, kolikrát je to ve věcech ne moc používaných a týkají se jen malého procenta atd. A další věcí je, co jsi do teď nepochopil, že všechny chyby v kernelu jsou zveřejněny, což nutně neznamená hned. Když se člověk koukne na to, co leze do widlí za aktualizace, opravdu dost pochybuju o tom, že jsou ve statistikách všechny, protože věci jako "kumulativní oprava zabezpečení libovolné kraviny" toho člověku fakt moc neřeknou.

Každopádně, stejně je to jedno, využívat díry se dnes ve velkém nevyplatí, jednodušší je zaměřit se na skupinu uživatelů nejmenovaného OS, odeslat jim nějakou kravinu mejlem, přiložit návod, jak vypnout antivir, kdyby náhodou prudil a je vymalováno.  :D

359
....Co se týče debugování,...
Psal sem v asm pro 8mibity, psal sem v asm pro x86 a semo tamo neco nekomu lehce crackoval. Ne, debugovanim rozhodne chybu o ktery predem nevis nenajdes (a chtel bych videt magora, kterej by se o to snazil). Naprosty nesmysl. Debugovanim se tak maximalne muzes na zaklade uz vyvolany chyby podivat, kde nechal tesar vrata od stodoly.

Kdyz mas zdrojak, muzes delat jeho analyzu, a predevsim muzes otestovat jednotlivy casti kodu. Ostatne 99% vsech nalezenych bugu je zalozeno na tom, ze se hledaji/a zkouseji uz znamy postupy. Novej postup se objevi prakticky vzdy jen nahodne, prevazne tak, ze nekde neco zbuchne a nekdo zacne zkoumat, jestli by toho neslo nejak vyuzit.
No však jsem to psal, že debugováním nic nenajde, pokud netuší co a kde hledá. Taky jsem svýho času něco málo crackoval, jen tak pro zábavu a nejrychlejší cestou - na pouhých pár hodin (velmi výjmečně do hodiny) bylo, pokud měl člověk k dispozici legální i nelegální verzi. Pokud ji neměl a soft obsahoval nějaký anti debug fičury, komprese, setkal jsem se třeba s programem, kterej byl kus po začátku zaxorovanej nějakým řetězcem a jako první se rozxorovával... to bylo na mnoho hodin až dní. A to se bavím o nějakým softu, kterej měl maximálně pár mega binárního kódu včetně knihoven a navíc jsem přesně věděl, co chci udělat. Hledat zranitelnost "nevím jakou, nevím kde, nevím proč", to je cesta do blázince a ne k úspěchu.

360
Vždyť si zase vymýšlíte. V případě Linuxu kernelový tým o zveřejnění vulnerability jedná s objevitelem a autory distribucí: A disclosure date is negotiated by the security team working with the bug submitter as well as vendors. Takže jsou veřejné přístupné informace jen u těch vulnerabilities, u kterých v daném čase nebylo dohodnuto s objevitelem zranitelnosti odložení zveřejnění.
https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html
Tak si to alespoň přečti...
The goal of the Linux kernel security team is to work with the bug submitter to bug resolution as well as disclosure. We prefer to fully disclose the bug as soon as possible. It is reasonable to delay disclosure when the bug or the fix is not yet fully understood, the solution is not well-tested or for vendor coordination. However, we expect these delays to be short, measurable in days, not weeks or months. A disclosure date is negotiated by the security team working with the bug submitter as well as vendors. However, the kernel security team holds the final say when setting a disclosure date. The timeframe for disclosure is from immediate (esp. if it’s already publicly known) to a few weeks. As a basic default policy, we expect report date to disclosure date to be on the order of 7 days.
Takže žádných běžných 90 dní, který kolikrát MS na opravu ani nestačí.
A mimochodem, on neřekl, že jsou informace dostupný hned, jen to, že se zvěřejní.

Stran: 1 ... 22 23 [24] 25 26 ... 99