Debian končí s podporou starých 32bitových procesorů

Hele takhle od pasu střílet na to co by to mohlo být, když není ponětí o tom co by to mohlo uvnitř dělat .... to je k ničemu. Stačí nějaký mnoho JOIN dotaz na blbě rozvržené tabulky a jsi tam 20 minut ...

Je jeden způsob jak to zjistit ...

Jestli to nebude tím, že napsat tu aplikaci lépe by vyšlo na mnohem víc, než prostě koupit pořádný hardware.

Jako ale fakt si nedovedu představit, když vezmu 250 výplat za měsíc, co se na tom dělá hodiny. Dělával jsem s fakt dlouhýma datama různých formátů a i ty největší, by se dali přirovnat k 15 - 20 000 výplatám třeba nejely více jak hodinu .... .... tam bude nějaká hrozný bota ....

Ehm ... zcela konkretni a zcela realny priklad ju? Jista dcerina CEZu (pokud si pamatuju IC energo nebo tak nejak se to menovalo), obsluhujici mimo jiny vejplaty vsech zamestnancu (cca 15k lidi). Jisty uzasny ERP - HeliosGreen (Green = nedovareny). Vyplatni termin meli nekde kolem 15. Vypocet tech vejplat ovsem trval ... 10 dnu (= meli maximalne +- 3 dny na zadani vsech potrebncyh dat). Takze pokud se neco podelalo, tak nemeli sanci stihnout termin.

A to nikoho nenapadlo, že spočítat výplaty podle dnešních zákonů může být opravdu takový voser, že to trvá stejně jako před dvaceti lety ma 386-ce?

Heh, tady je znalcu.

Spocitat vyplatu pro 250 lidi zvladne excelova tabulka za par milisekund.

Kdejaky jouda nazyva "pocitani vyplat" business proces zahrnujici napr. odpocet zamestnaneckych bonusu z "cafeterie" se spravnym zauctovanim, hromadu reportu ze SAP dat generovanych pro financak, ossz, statisticky urad. Nedejboze kdyz tak jsou nejake zahranicni sluzebky. Business reporty plneni financniho cile, mapovani workloadu na nakladova centra, projekty. Vypocet trendu cashflow, obsluha revolvingoveho uveru. Zapracovani nakladu na sluzebni vozidla z automaticke knihy jizd. Automaticky fraud detector a reporty pro controlling. Vedeni kasy a vedeni kasy zahranicnich men.
Prouctovani soukromych/firemnch vydaju zamestnancu. Zpracovani dat z CCSek a firemnich kreditek.

Jo, vsecko thle delala ta foxka v roce 95...

Je to neuveritelny co? Ale vazne mas, viz vejs. Zapocitavat do procesu vypoctu nejaky sosani externich dat bych se vubec neodvazoval. Proste se bavime vyhradne o stavu, kdyz ucetni spusti funkci "vypocet mezd". A tudiz defakto vyhradne o tom, ze je treba trivialne poscitat mzdove slozky, odecist nezdanitelne castky, vypocitat dane ... a vygenerovat nejakej hromadnej platebni prikaz.

Na tohle je jednoduchy test.
Staci se podivat, kolik je behem vypoctu REALNE zatizeni serveru.

Protoze kdyz je z 32 jader vytizene jedno na pul procenta, moc rychle to nepojede a nejspis se na neco externiho ceka.

Nebo nedej bože když mají 3 zaměstnanci z 20ceti násobnou exekuci. To se z toho může pak každá mzdovka posrat a je úplně jedno jakej systém/hw/účet­nictví používá.

No to víš, když dělají numerickou integraci nákladů po 15 minutách a počítající superstroj se ptá docházkovýho terminálu na zákeřný otázky jako "Když byl 1.1. 9:00 - 9:15 státní svátek, byl státní svátek i 1.1. 9:15-9:30?" a ověřuje si dotazem do databáze, jestli v neděli ve 20:30 byla furt ještě neděle, tak se nediv.

A až začnou zpětně ověřovat online každou čtvrthodinu na matrice, jestli je furt stejný počet dětí a manželek kvůli slevě na dani, to teprve bude hukot... :D

:-D Pobavilo :-D

To není o zákonech. To je o tom, co všechno chtějí zákazníci, aby ten systém sám započítal. Ten seznam funkcí u moderních systémů je na několik stránek a u řady věcí by vás na první pohled ani nenapadlo, že to vlastně mzdový systém počítat musí. Plno z těch věcí se dříve řešilo tak, že se počítaly stranou v jiných systémech nebo "systémech" (např. na evidenci aut stačila tabulka v Excelu) a do mzdového se to předalo stylem "přičti/odečti XY v kolonce ABC".

Ale je fakt, že personální systémy, co znám, dokáží počítat 1000 lidí za hodinu se vším všudy. Takže tam si bude opravdu nějaký problém i v tom SW.

V roce 1998 na Pentiu počítal jeden mzdový systém 3000 lidí za hodinu. Jiný, Linuxový, zvládal stejný počet za pár minut. Rozdíl byl v rozsahu vstupních dat. Ten Windowsový uměl takové věci, že se člověku v měsíci měnila tarifní mzda, umělo to dopočítat bonusy z projektů, samo to tahalo data z docházkového systému a počítalo úvazky atd. Ten Linuxový trval na tom, že člověk měl v daném období jen jediný pracovní vztah a jednu mzdovou třídu. Bonusy apod. šly zadávat jen jako pevná částka nebo procento ze základní hrubé mzdy. Docházka se tomu musela dodat předchroustaná: člověk, hodin odpracováno, hodin dovolené, hodin absence atd. Prostě toho ten Windowsovský uměl mnohem víc. A to byly oba od stejné firmy a Linuxový program měl navíc technologickou výhodu oproti tomu kousku běžícímu na MS Windows 95.

Takže podle mne je opravu zásadní otázka ta, co vlastně která verze doopravdy počítala. Protože "výpočet mezd" se dá napsat i jako vzrorec do MS Excel a bude to počítat tisíce lidí za sekundu. Pokud tedy budete mít v jedné záložce seznam lidí, jejich hrubou měsíční mzdu, hodiny odpracované a hodiny dovolené. Tak snadný ten výpočet je. Problém je, že dnes zákazníci chtějí, aby to odpracované hodiny počítalo samo, aby to počítalo nárok na stravenky, samo započítalo exekuce, umělo to změnu úvazku v průběhu měsíc, umělo to úkolovou mzdu, umělo to premie, umělo to bonusy za projekty, umělo to zálohy, umělo to služební auta (ze služebního auta platí zaměstnanec daně), umělo to kdejakou úžasnost, kterou si vedení společnosti vymyslelo na motivaci zaměstnanců (např. vital pass), aby to samo hlídalo pracovní výročí, jednorázové příspěvky např. na dopravu, za doporučení nového zaměstnance, za narození dítěte, umělo to relokační příspěvky, spoluúčast na investicích (např. zaměstnanec si platí 10% z ceny jazykového kurzu), vymáhání náhrady škody (zmetky, nabouraný vozík), vše samozřejmě podle dohodnutého splátkového kalendáře. Plus navíc něco, co na první pohled na výplatní pásce nevidíte: aby to veškeré peníze reportovalo i s nákladovým střediskem. Prostě se rok od roku kumplikuje zadání. Pod pojmem "spočítat mzdy" si zákazníci představují stále širší množinu informací.

Pocitanim vejplat se v tomto pripade zcela jednoznacne mini stav, kdy jsou VSECHNA data v JEDNOM systemu = ucetni vse zadala, at uz rucne nebo pomoci nejakych importu z dochazky atd.

Tak ale stěžoval si, že je to nyní na lepším železe a trvá to stejně, tedy bych si tipnul, že tem budou nějaké prodlevy na bázi té aplikace. Něco jako třeba, a teď fakt si zafantazíruju ale už jsem takový kód viděl:
Je tam dotaz na DB, který někdo pustil ve smyčce třeba 5000x a protože mu to v půlce padalo, tak tam dal 3s zpoždění. a hned je 250 min zpoždění ....