Názory k článku
Debian končí s podporou starých 32bitových procesorů
-
Skoro bych řekl, že to škoda je. Procesory modernější, než P4 už dávno měly přejít na 64bitovou verzi. Naopak pro majitele starého železa je to podraz a to tím spíš, že u téhle skupiny uživatelů (mimo jiné, samozřejmě) je Debian jedno z nejoblíbenějších dister. Tenhle Debian i686 je jaksi v zemi nikoho.
-
Ondra Satai NekolaZlatý podporovatelJasne, protoze ATckove zdroje nikdy nevzaly s sebou zbytek pocitace, kondiky nevytekaly, pokud jsi mel blizko Socket 7... A vubec se v devadesatkach nepocitalo s rocnim az dvouletym cyklem na obnoveni HW a vubec to, co vidis dnes za zbytky neni vyjimka z pravidla, ktere je jinak davno na smetisti.
-
Nevim, sa cim se pocitalo, ale skutecnost je takova, ze ty stare kramy drzely vic. Jednak byly pajene olovnatou pajkou, jednak se podstatne mene hraly. Jeste nektera Pentia se dala honit bez chladice, dnes je spousta veci horka, jak zehlicka, i s chladicem.
Krome toho, pocitace tehdy nebyly zadarmo. Dneska se kolikrat da poridit za cenu, ktera tehdy byla nemyslitelna. Takze tim pouze dvouletym cyklem bych si nebyl jisty, zejmena, kdyz na tom byl DOS se tremi aplikacemi, kde ten vykon vetsinou nebyl moc potreba a upgrade by se nevyplatil.
-
j (neregistrovaný)
Na i386 s 1MB RAM se vejplaty pro 250 lidi pocitaly cca 2-3 hodky .... na 2xXeonu s 2x8jadry + totez na SQL + nejakych 128GB RAM + diskovy pole .... se vejplaty pro stejnej pocet lidi pocitaj ... taky 2-3 hodiny ... kua, neco je spatne.
Jinak vubec nejde o stary vykopavky, ty CPU se normalne furt vyrabej a pouzivaj. Samo ne do desktopu, ale najdes je ve spouste ruznych vecech.
-
Holt moderni technologie. U nas delaly fakturaci zenske na nejakych 15 PC s 286kama. Na dalsim PC byla 486 s Novelem 4.x a dvema diskam 200 MB v zrcadle - to byl tehdy desny luxus. Na serveru byla jen databaze, klienti meli jakysi databazovy system preneseny z NIXu, na kterem lokalne klapaly faktury a jely jako fretka. Kdyz jich mely dost napsanych, poslaly je na Novela tak, ze si ta vec zamkla celou databazi a pridala zaznamy, takze se nemuselo resit zamykani zaznamu. To vse pres tenky Ethernet.
Pocitam, ze dnes tam maji nejakou widloaklikaci, soupaj mysi, az se kouri z podlozky a jde jim to petkrat pomaleji.
-
Ondra Satai NekolaZlatý podporovatel
Hele - a jsi si jisty, ze to pocitani vyplat je to same jako to pocitani vyplat?
-
Ondra Satai NekolaZlatý podporovatel
A nenapadlo te trebas, ze v roce raz dva tam meli par tezko prepdripravovanych flat souboru zatimco ted to pocitani vyplat obnasi sezobani potrebnych informaci z par externich systemu, napriklad?
-
Napadlo, ale i tak si myslim, ze pokud vypocet na takove vypocetni sile trva porad stejne, jako na i386, tak je nekde neco blbe. To tam ke kazdemu zamestnanci znovu stahuji zakonik prace a analyzuji ho pomoci umele inteligence?
Ostatne i ty dve az tri hodiny na i386 pro 250 lidi mi pripada hodne. To to tam snad museli mit napsane v dBase nebo co, ta byla na rychlost totalne strasna a kdyz byl nekdo debil, dokazal vse napsat jeste i pomaleji.
-
Ondra Satai NekolaZlatý podporovatel
Stejne jedina podstatna otazka je - pocita to spravne a v case, ktery te firme vyhovuje?
-
Jenom to? A co treba otazka, zda naklady na porizeni vypoctni a ulozne kapacity nejsou neprimerene vysoke na to, ze to pocita jen 250 vyplat? Tohle by melo zvladnou i stare Pentium s FoxPro v podstatne kratsim case, jen by aplikace musela byt napsana jinak. Kdyz to trva tak dlouho na takovem HW, podeziram, ze se musi jednat o strasny bastl, ktery by mel jit na hovnokod.cz
-
Ano, to je obvykla vymluva v pripadech, kdy apklikaci bastli lepic, ktery si v necem naklika interfejs, ze ktereho mzdovym ucetnim naskakuji pupinky a maji nocni mury. K tomu pak prilepi databazi, o ktere hovno vi a tak ji vyuziva stylem, ktery zpusobuje nemoznou odezvu (problem, ktery se zde v diskusich vyskytuje dost casto). Nasledne to obali spatnou a spatne naprogramovanou matikou a vysledek je vypocet 2 az 3 hodiny na nadupane masine s databazi na dalsi nadupane masine.
Fuj, kdyz si vzpomenu, jaky hukot se dal vyrazit na 486 ze stareho FoxPra, kdyz makalo nad databazemi o desitkach MB prolinkovanymi pres klice.... Hlavne, ze SQL databaze jsou o tolik uzasnejsi, nez prasacke FoxPro. Jen kdyby je lidi umeli pouzivat, jak se ma.
-
K D (neregistrovaný)
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 ....
-
j (neregistrovaný)
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.
-
Před rokem 2004 důchody pro 60000 lidí počítala DOS aplikace 2 až 3 hodiny. Po přepsání do SQL databáze (Firebird, co vím, běží to na něm dodnes, jen je povyšována verze) trval výpočet 15 minut. GUI klasicky v Delphi, ty tehdy frčely, ale to je nepodstatné, celý výpočet vlastně běžel v uložených procedurách v db. Takže když se chce, jde to. A ano, ta aplikace by oprávněně patřila na hovnokod.cz, když si vezmu, jak jsme psali kód tehdy, zvolená architektura a tak :-).
-
Youda (neregistrovaný)
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...
-
Jo, vsecko thle delala ta foxka v roce 95...
Ne, nedelala, nicmene ten bypocet by zvladla. Ostatne jsem videl "SAP" prepsany do dBase.
Nicmene i s tim, co pises, myslis si, ze by to melo trvat dele, nez tech par desitek minut? To tam jako vsech 50 zamestnancu jezdi firemnim autem na sluzebni cesty trikrat tydne? Nebo odpocet jednoho cisla z kafeterie trva deset minut?
-
Ondra Satai NekolaZlatý podporovatel
Ty jsi nikdy neprgal, co?
Mej to rozhazene po par systemech za nejakym remote API a z tech dvou hodni travis dve hodiny cekanim. Naopak kdyz uz mas na jednom miste data, tak za par desitek minut udelas i celkem netrivialni vypocty nad miliony radku...Podle takovehle anekdoty tezko soudit, urcite nema smysl byt takovy strelec jako ty nebo j.
-
Ondra Satai NekolaZlatý podporovatel
Proc mluvis o vecech, kterym nerozumis? Tenhle problem je u dost starsi nez cloud. Ono zase rvat vsechno na jedno misto prinese uplne jine bolesti.
-
Ondra Satai NekolaZlatý podporovatel
A ty si vazne myslis, ze uz mas vsechna potrebna data na tom stroji s databazi? Staci ti trebas nutnost zacit dotahovat neco po siti - a pokud mas smulu a pouzivane API nema zrovna povedenou fasadu a musis volat pro kazdou polozku neco po siti... tak ti co polozka skoci call na desitky nebo stovky milisekund.
-
Tak data se tahaji po siti tak, jako tak, kdyz to delaji na dvou strojich. A jestli tam maji nepovedene API, tak proc tam maji nepovedene API? Jiste, jim to treba je jedno, ze to trva tri hodiny, protoze tech vyplat delaji jen 250. Ale problem je v tom, ze nekdo udelal blbe API, cili neco je spatne a o tom, ze neco je spatne, je tu celou dobu rec.
-
j (neregistrovaný)
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.
-
Ondra Satai NekolaZlatý podporovatel
Trvalo by to nejspis stejne. Ukol zabere cas k nemu urceny.,..
-
Kod jsi sice nevidel, ale neni divne, ze pri narustu vykonu CPU oproti 386, ktere jsou navic dva a maji vic, jak jedno jadro a pri narustu propustnosti diskoveho pole ve srovnani s nejakym stary STxxxx na AT busu, mame porad stejny cas vypoctu? To opravdu neni normalni, kdyz vykon CPU od te doby vzrostl tak minimalne o tri rady na kazdem jadre. Vzrostla komplexita vypoctu vyplaty take o tri rady, k tomu vynasobena poctem jader?
-
Petr M (neregistrovaný)
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
-
Karel (neregistrovaný)
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.
-
Karel (neregistrovaný)
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í.
-
K D (neregistrovaný)
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í ....
