pretoceny uptime :)
Michael Mraka
kratkou historku:
----
Nedavno jsem si vsiml, ze jeden z nasich pocitacu, ma uptime 495 dnu.
Tak jsem se zacal tesit, jak male dite, ze se pokocham pohledem na
uptime >500 dnu, ale misto toho me po prihlaseni cekalo prekvapeni v podobe
uptime 3 dny.
To me nastvalo --- pocitac je na UPS a zadne problemy nehlasil, tak jak se to
ksakru mohlo stat --- a tak (nez najdu nekoho komu bych vynadal :) jsem zacal
hledat kvuli cemu to rebootovalo.
Jenze jsem nic nenasel...
V tuto chvili ve mne zacalo hlodat podezreni, ktere se potvrdilo pri
pohledu do zdrojaku jadra --- zadny vypadek se nekonal, jenom se povedlo
pretocit 32bit counter, ze ktereho se pocita uptime :).
----
--mm Michael Mráka
---------------------------------------------------------------------------
Meta-FAQ (odhlášení, archív, FAQ a další): http://www.linux.cz/mailing-list
TIP: Jak na lokalizaci? Czech Howto! http://www.penguin.cz/czech-howto/
Roman DAVID
> .........
> Nedavno jsem si vsiml, ze jeden z nasich pocitacu, ma uptime 495 dnu.
> Tak jsem se zacal tesit, jak male dite, ze se pokocham pohledem na
> uptime >500 dnu, ale misto toho me po prihlaseni cekalo prekvapeni v podobe
> uptime 3 dny.
> V tuto chvili ve mne zacalo hlodat podezreni, ktere se potvrdilo pri
> pohledu do zdrojaku jadra --- zadny vypadek se nekonal, jenom se povedlo
> pretocit 32bit counter, ze ktereho se pocita uptime :).
To jste me nepotesil :-(
Ja se momentalne blizim k 400 a na 500 jsem planoval
nejakou oslavu ...
Takze jak to tak vidim, snazit se o nejvyssi uptime
nema vyznam. :-(
Roman DAVID
---------------------------------------------------------------------------
Meta-FAQ (odhlášení, archív, FAQ a další): http://www.linux.cz/mailing-list
TIP: Hledate software? Zkuste http://freshmeat.net/
Zdenek Pytela
> V tuto chvili ve mne zacalo hlodat podezreni, ktere se potvrdilo pri
> pohledu do zdrojaku jadra --- zadny vypadek se nekonal, jenom se povedlo
> pretocit 32bit counter, ze ktereho se pocita uptime :).
do novejsich, jestli je to opravene, jinak je to na bugreport ;-).
Zdravi
--
--Zdenek Pytela, <le...@mrakoplas.phil.muni.cz>
---------------------------------------------------------------------------
Meta-FAQ (odhlášení, archív, FAQ a další): http://www.linux.cz/mailing-list
TIP: Konference o sendmailu jinych MTA: sendma...@linux.cz
Jirka Kosina
> > V tuto chvili ve mne zacalo hlodat podezreni, ktere se potvrdilo pri
> > pohledu do zdrojaku jadra --- zadny vypadek se nekonal, jenom se povedlo
> > pretocit 32bit counter, ze ktereho se pocita uptime :).
> To je hezka historka. V jakem to bylo jadre? Chtelo by to podivat se
> do novejsich, jestli je to opravene, jinak je to na bugreport ;-).
No, v LKML se o tom vedla diskuze - je to known bug, ale oba dva
navrhovane patche zpusobily nefunkcnost jinych casti systemu, tak se to
docasne uzavrelo s tim, ze je to vlastne celkem jedno ;)
--
JiKos.
---------------------------------------------------------------------------
Meta-FAQ (odhlášení, archív, FAQ a další): http://www.linux.cz/mailing-list
Jan Kasprzak
: Michael Mraka píše:
: > V tuto chvili ve mne zacalo hlodat podezreni, ktere se potvrdilo pri
: > pohledu do zdrojaku jadra --- zadny vypadek se nekonal, jenom se povedlo
: > pretocit 32bit counter, ze ktereho se pocita uptime :).
: do novejsich, jestli je to opravene, jinak je to na bugreport ;-).
Myslim ze se o tomhle diskutovalo a bylo to uznano jako nevhodne,
protoze detekce pretoceni jiffies by zpusobila vetsi narocnost preruseni
od casovace a nestoji to za to zpomaleni.
-Y.
--
| Jan "Yenya" Kasprzak <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/ Czech Linux Homepage: http://www.linux.cz/ |
---------------------------------------------------------------------------
Meta-FAQ (odhlášení, archív, FAQ a další): http://www.linux.cz/mailing-list
Michael Mraka
% Michael Mraka píše:
% > V tuto chvili ve mne zacalo hlodat podezreni, ktere se potvrdilo pri
% > pohledu do zdrojaku jadra --- zadny vypadek se nekonal, jenom se povedlo
% > pretocit 32bit counter, ze ktereho se pocita uptime :).
% To je hezka historka. V jakem to bylo jadre? Chtelo by to podivat se
% do novejsich, jestli je to opravene, jinak je to na bugreport ;-).
Je to distribucni 2.2.14 z RedHatu (tusim 6.2).
Myslim, ze to nikdo zatim neopravil, ale na bugreport to urcite je...
prece se nenechame okradat o nas tvrde zaslouzeny uptime :).
--mm Michael Mráka
---------------------------------------------------------------------------
Meta-FAQ (odhlášení, archív, FAQ a další): http://www.linux.cz/mailing-list
TIP: Konference o UNIXu obecne: munix-l na list...@muni.cz
Michael Mraka
% Michael Mraka wrote:
% > .........
% > Nedavno jsem si vsiml, ze jeden z nasich pocitacu, ma uptime 495 dnu.
% > .........
% > Tak jsem se zacal tesit, jak male dite, ze se pokocham pohledem na
% > uptime >500 dnu, ale misto toho me po prihlaseni cekalo prekvapeni v podobe
% > uptime 3 dny.
%
% > V tuto chvili ve mne zacalo hlodat podezreni, ktere se potvrdilo pri
% > pohledu do zdrojaku jadra --- zadny vypadek se nekonal, jenom se povedlo
% > pretocit 32bit counter, ze ktereho se pocita uptime :).
%
% To jste me nepotesil :-(
% Ja se momentalne blizim k 400 a na 500 jsem planoval
% nejakou oslavu ...
Tak to budete muset snist ty chlebicky uz pri 497 :).
% Takze jak to tak vidim, snazit se o nejvyssi uptime
% nema vyznam. :-(
%
% Roman DAVID
--mm Michael Mráka
---------------------------------------------------------------------------
Meta-FAQ (odhlášení, archív, FAQ a další): http://www.linux.cz/mailing-list
Zdenek Pytela
> Myslim ze se o tomhle diskutovalo a bylo to uznano jako nevhodne,
> protoze detekce pretoceni jiffies by zpusobila vetsi narocnost preruseni
> od casovace a nestoji to za to zpomaleni.
půl objeví tak závažná chyba v jádře, že se tak jako tak musí přebootovat.
Ještěže u nás vypadává proud na takovou dobu, že jsem na tento 'problém'
nenarazil.
--
--Zdeněk Pytela, <le...@mrakoplas.phil.muni.cz>
---------------------------------------------------------------------------
Meta-FAQ (odhlášení, archív, FAQ a další): http://www.linux.cz/mailing-list
Libor Chocholaty
> Zdenek Pytela wrote:
> : Michael Mraka píše:
> : > V tuto chvili ve mne zacalo hlodat podezreni, ktere se potvrdilo pri
> : > pohledu do zdrojaku jadra --- zadny vypadek se nekonal, jenom se povedlo
> : > pretocit 32bit counter, ze ktereho se pocita uptime :).
> : To je hezka historka. V jakem to bylo jadre? Chtelo by to podivat se
> : do novejsich, jestli je to opravene, jinak je to na bugreport ;-).
>
> Myslim ze se o tomhle diskutovalo a bylo to uznano jako nevhodne,
> protoze detekce pretoceni jiffies by zpusobila vetsi narocnost preruseni
> od casovace a nestoji to za to zpomaleni.
>
A coz to resit 64bit citacem? Nebylo by to elegantni oddaleni problemu?
Libor
---------------------------------------------------------------------------
Meta-FAQ (odhlášení, archív, FAQ a další): http://www.linux.cz/mailing-list
Libor Chocholaty
> On Wed, 10 Apr 2002, Zdenek Pytela wrote:
>
> > > V tuto chvili ve mne zacalo hlodat podezreni, ktere se potvrdilo pri
> > > pohledu do zdrojaku jadra --- zadny vypadek se nekonal, jenom se povedlo
> > > pretocit 32bit counter, ze ktereho se pocita uptime :).
> > To je hezka historka. V jakem to bylo jadre? Chtelo by to podivat se
> > do novejsich, jestli je to opravene, jinak je to na bugreport ;-).
>
> No, v LKML se o tom vedla diskuze - je to known bug, ale oba dva
> navrhovane patche zpusobily nefunkcnost jinych casti systemu, tak se to
> docasne uzavrelo s tim, ze je to vlastne celkem jedno ;)
>
Jasne, chybu, kterou nedokazu opravit, prohlasim za vlastnost nebo za tak
nedulezitou, ze se tim nebudu zabyvat. At ziji 64bit citace :-)
Libor
---------------------------------------------------------------------------
Meta-FAQ (odhlášení, archív, FAQ a další): http://www.linux.cz/mailing-list
ViNiL
> Jan Kasprzak wrote:
> > Myslim ze se o tomhle diskutovalo a bylo to uznano jako nevhodne,
> > protoze detekce pretoceni jiffies by zpusobila vetsi narocnost preruseni
> > od casovace a nestoji to za to zpomaleni.
> >
>
> A coz to resit 64bit citacem? Nebylo by to elegantni oddaleni problemu?
Pokud sedite na 32-bitovem stroji, tak to neni dobry napad. S jiffies se
pracuje v podstate furt, takze ta rychlost je jaksi esencialni...
--
ViNiL the GNU hippie
Nejdříve stvořil Bůh muže, pak ženu. Potom mu přišlo muže líto a
dal mu tabák.
-- Mark Twain
---------------------------------------------------------------------------
Meta-FAQ (odhlášení, archív, FAQ a další): http://www.linux.cz/mailing-list
TIP: Prectete si Linux Documentation Project: http://www.linux.cz/linuxdoc/
Pavel Kankovsky
> Myslim ze se o tomhle diskutovalo a bylo to uznano jako nevhodne,
> protoze detekce pretoceni jiffies by zpusobila vetsi narocnost preruseni
> od casovace a nestoji to za to zpomaleni.
Ano...jedna instrukce navic (na i386) pri kazdem preruseni, to mame
nejakych 100-300 tiku za sekundu (pro HZ = 100), to muze lecktery pocitac
zpomalit i o jednu miliontinu!! ;)
On Wed, 10 Apr 2002, Libor Chocholaty wrote:
> A coz to resit 64bit citacem? Nebylo by to elegantni oddaleni problemu?
Rozsireni citace na 64 bitu by problem oddalilo asi o 10 miliard let.
Myslim, ze na to lze bez problemu aplikovat pristup meho kolegy, ktery
prohlasil (necitovano presne), "vim, ze <program> ma problem Y10K-problem,
ale odmitam to resit, dokud to nebude aktualni". :)
--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."
---------------------------------------------------------------------------
Meta-FAQ (odhlášení, archív, FAQ a další): http://www.linux.cz/mailing-list
TIP: Prohledejte ftp.linux.cz: http://ftp.linux.cz/pub/
Jan Kasprzak
: On Wed, 10 Apr 2002, Jan Kasprzak wrote:
:
: > Myslim ze se o tomhle diskutovalo a bylo to uznano jako nevhodne,
: > protoze detekce pretoceni jiffies by zpusobila vetsi narocnost preruseni
: > od casovace a nestoji to za to zpomaleni.
:
: Ano...jedna instrukce navic (na i386) pri kazdem preruseni, to mame
: nejakych 100-300 tiku za sekundu (pro HZ = 100), to muze lecktery pocitac
: zpomalit i o jednu miliontinu!! ;)
A spinlock kolem. Urcite vic nez 1 instrukce.
-Y.
--
\ Jan "Yenya" Kasprzak <kas at fi.muni.cz> http://www.fi.muni.cz/~kas/
\\ PGP: finger kas at aisa.fi.muni.cz 0D99A7FB206605D7 8B35FCDE05B18A5E //
\\\ Czech Linux Homepage: http://www.linux.cz/ ///
When I have a house, I'd rather own my house and take the problems than rent
it. And I think the same is true about software. --Linus Torvalds
Libor Chocholaty
> > A coz to resit 64bit citacem? Nebylo by to elegantni oddaleni problemu?
>
> Rozsireni citace na 64 bitu by problem oddalilo asi o 10 miliard let.
> Myslim, ze na to lze bez problemu aplikovat pristup meho kolegy, ktery
> prohlasil (necitovano presne), "vim, ze <program> ma problem Y10K-problem,
> ale odmitam to resit, dokud to nebude aktualni". :)
>
Ale jak vidno, tendo problem _je_ aktualni. Nekterym z nas znemoznil konani
oslavy. :-)
Myslim, ze se najdou i padnejsi duvody...
Libor
---------------------------------------------------------------------------
Meta-FAQ (odhlášení, archív, FAQ a další): http://www.linux.cz/mailing-list
TIP: Hardwarova kompatibilita? http://hardware.penguin.cz/
Pavel Kankovsky
> : Ano...jedna instrukce navic (na i386) pri kazdem preruseni, to mame
> : nejakych 100-300 tiku za sekundu (pro HZ = 100), to muze lecktery pocitac
> : zpomalit i o jednu miliontinu!! ;)
> :
> A spinlock kolem. Urcite vic nez 1 instrukce.
Na co spinlock? Kvuli kolizi dvou zapisu je zbytecny: ty by se mely
odehravat jen v preruseni od hodin a ty by mely byt serializovane. Kvuli
kolizi zapisu a cteni je take zbytecny, protoze:
1. vetsina kodu vystaci jen s jiffies mod 2^32 (ze stejneho duvodu, proc
system nezkolabuje nyni, kdyz se to pretoci), a tudiz jen atomicky
nacte dolni pulku hodnoty,
2. kod, ktery potrebuje obe hodnoty, je muze precist nasledujicimi
prikazy (v praxi by to muselo byt v asembleru, nebo by se tam muselo
rozhodit par volatile, aby to kompilator nevyoptimalizoval do
ztracena):
uint32_t jlo, jhi;
do {
jhi = jiffies_high;
jlo = jiffies_low;
}
while (jhi != jiffies_high);
Donekonecna se ta smycka zacyklit nemuze: to by se muselo inkrementovani
jiffies zastavit, nebo by se ten proces musel opakovane blokovat na onech
radove 500 dni -- uvnitr jadra!!! Spatne vysledky by to mohlo davat jedine
v pripade, ze by zapisy 32-bitovych hodnot do pameti nebyly atomicke, nebo
ze by se dva zapisy provedene po sobe jednim CPU mohly na jinem CPU jevit,
ze byly provedene v opacnem poradi -- ovsem i kdyby uz navrhari procesoru
byli dost sileni, aby neco takoveho udelali, pak by to stejne melo jit
jednoduse vyresit nejakou "barierovou instrukci" (jinak nevim, jak by
nekdo mohl z takovych CPU postavit fungujici SMP pocitac).
On Fri, 12 Apr 2002, Libor Chocholaty wrote:
> > > A coz to resit 64bit citacem? Nebylo by to elegantni oddaleni problemu?
> >
> > Rozsireni citace na 64 bitu by problem oddalilo asi o 10 miliard let.
> > Myslim, ze na to lze bez problemu aplikovat pristup meho kolegy, ktery
> > prohlasil (necitovano presne), "vim, ze <program> ma problem Y10K-problem,
> > ale odmitam to resit, dokud to nebude aktualni". :)
> >
> Ale jak vidno, tendo problem _je_ aktualni. Nekterym z nas znemoznil konani
> oslavy. :-) Myslim, ze se najdou i padnejsi duvody...
Ja jsem se asi nevyjadril uplne srozumitelne: mel jsem na mysli, ze
po rozsireni citace na 64 bitu by se problem oddalil tak daleko, ze by se
z praktickeho hlediska definitivne vyresil.
--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."
---------------------------------------------------------------------------
Meta-FAQ (odhlášení, archív, FAQ a další): http://www.linux.cz/mailing-list
TIP: Prectete si obcas znovu Meta-FAQ
Pavel Kankovsky
> 2. kod, ktery potrebuje obe hodnoty, je muze precist nasledujicimi
> prikazy (v praxi by to muselo byt v asembleru, nebo by se tam muselo
> rozhodit par volatile, aby to kompilator nevyoptimalizoval do
> ztracena):
>
> uint32_t jlo, jhi;
> do {
> jhi = jiffies_high;
> jlo = jiffies_low;
> }
> while (jhi != jiffies_high);
>
Uff...tak to se trochu nepovedlo. Omlouvame se ctenemu publiku za
snizenou kvalitu citovaneho prispevku zpusobenou zkratem v mentalnim
procesu autora. Tohle by fungovalo pouze za predpokladu, ze zapisujici
CPU zapisuje dost rychle. Coz je asi ponekud odvazny predpoklad. Spravne
reseni (snad <g>), ktere je o neco slozitejsi, je nasledujici:
A. Mame 32-bitove tri promenne: jiffies_low, jiffies_high a jiffies_low2
inicializovane na zacatku nulami (pripadne jinymi hodnotami, ale musi
na zacatku platit, ze j_low == j_low2).
B. Zapis probiha takto:
1. inkrementuje se jiffies_low,
2. inkrementuje se jiffies_high, pokud se jiffies_low pretocilo,
3. inkrementuje se jiffies_low2 (nebo ze zkopiruje hodnota z j_low).
Pritom musi platit, ze ctenari vidi zapisy provedene ve stejnem poradi,
v jakem jsou tady uvedeny, coz muze vyzadovat pridani nejakych
barierovych instrukci zde a mozna i behem cteni (*).
C. Cteni probiha takto:
1. precte se jiffies_low2 a ulozi do lokalni promenne,
2. precte se jiffies_high a ulozi do lokalni promenne,
3. precte se jiffies_low a ulozi do lokalni promenne,
4. porovnaji se prectene hodnoty jiffies_low a jiffies_low2, a pokud
jsou ruzne, pak se opakuje od kroku 1.
Predpoklada se, ze proces provadejici cteni se nemuze zablokovat na
dost dlouho, aby se mezitim pretocila dolni pulka. Zaroven se
predpoklada, ze je zanedbatelna pravdepodobnost, ze se opakovane
strefi do aktualizace jiffies (asi by ale slo zeslabit predpoklad na
rovnost j_low a j_low2 na neco jako j_low2 <= j_low, aby se opakovalo
jen v pripade, ze to zrovna preteklo, protoze jindy k zadne zmene
j_high nedochazi).
Dukaz spravnosti: Oznacme zapisy do jiffies_* pro strucnost wlo, whi, wl2
(low2) a cteni rlo, rhi, rh2. Relace < necht popisuje poradi, ve kterem
jsou operace provadeny (za jiz zminovanych predpokladu atomicnosti a
zachovani poradi zapisu vzhledem ke cteni; pokud nas zaroven nezajima
vzajemne poradi cteni v ruznych procesech, muzeme operace povazovat za
jednoznacne serializovatelne). Pak z popisu zapisu a cteni plati, ze:
a) wlo < whi < wl2, b) rl2 < rhi < rlo. Predpokladejme dale splneni
predpokladu uvedeneho u popisu cteni, tj. toho, ze lze zanedbat moznost,
ze mezi rl2 a rlo dojde k pretoceni jiffies_low*. Pak muze proces cteni
vydat nespravny (nekonzistentni) vysledkem pouze jsou-li vzhledem k zapisu
splneny nasledujici predpoklady: a1) wlo < rlo & wl2 < rl2 (zapisy j_low i
j_low2 probehnout drive nez cteni), a2) rhi < whi (zapis do j_hi probehne
pozdeji nez cteni), nebo b1) rlo < wlo & rl2 < wl2, b2) whi < rhi
(tj. zrcadlove). V obou pripadech lze snadno dojit ke sporu:
ad a) wl2 < rl2, & rl2 < rhi ==> wl2 < rhi, & rhi < whi ==> wl2 < whi!
ad b) rlo < wlo, & wlo < whi ==> rlo < whi, & whi < rhi ==> rlo < rhi!
Jeste by se melo ukazat, ze problemy nemohou nastat kvuli kolizi jednoho
cteni s vice zapisy (avsak mene nez 2^32), ale to se mi uz nechce delat a
stejne je to intuitivne jasne. :)
Jak vidno, je to trochu komplikovanejsi (zapis vyzaduje dve aritmeticke
operace navic a pripadne i dve bariery), ale porad by to melo byt znatelne
levnejsi nez spinlocky.
(*) Mam ale dojem, ze na i386 (aspon na modelech dost starych, aby
se tam vyskytoval problem uptime >= 500 dni <g>) nejsou potreba zadne.
--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."
---------------------------------------------------------------------------
Meta-FAQ (odhlášení, archív, FAQ a další): http://www.linux.cz/mailing-list
TIP: Hledate Linuxovy software? Zkuste http://www.tuxfinder.com/
Milan Sorm
# Jan Kasprzak píše:
# > Myslim ze se o tomhle diskutovalo a bylo to uznano jako nevhodne,
# > protoze detekce pretoceni jiffies by zpusobila vetsi narocnost preruseni
# > od casovace a nestoji to za to zpomaleni.
# O tomhle jsem nevěděl, škoda. Ale co, ona se stejně jednou za rok a
# půl objeví tak závažná chyba v jádře, že se tak jako tak musí přebootovat.
# Ještěže u nás vypadává proud na takovou dobu, že jsem na tento 'problém'
# nenarazil.
vypadek proudu nase ups a diesely ustoji, ale obcasnou navstevou zenske v
mzdovem tarifu jedna nebo dve s kostetem v ruce neodola ani sun, natoz
nejake pc... otazkou na nase vedeni pak je, proc maji uklizecky na cipovych
kartach maximalni opravneni???
--milan
---------------------------------------------------------------------------
Meta-FAQ (odhlášení, archív, FAQ a další): http://www.linux.cz/mailing-list
TIP: Tato konference je dostupna i jako cz.comp.linux
Zdenek Mazanec
> mzdovem tarifu jedna nebo dve s kostetem v ruce neodola ani sun, natoz
> nejake pc... otazkou na nase vedeni pak je, proc maji uklizecky na
cipovych
> kartach maximalni opravneni???
IMHO kvuli tomu, ze bezny admin se dostatecne casto popeli v prachu
serverovny kvuli nejruznejsim sborkam a rozborkam. Kdyby mu nekdo pristrcil
k ruce mop a vysavac s tim, ze ma uklidit vic nez jen "sve" stroje, tak by
slo dotycnemu o zivot bez ohledu na jeho formalni postaveni ;-)
Zdenek Mazanec
---------------------------------------------------------------------------
Meta-FAQ (odhlášení, archív, FAQ a další): http://www.linux.cz/mailing-list
Marek Blasko
> mzdovem tarifu jedna nebo dve s kostetem v ruce neodola ani sun, natoz
> nejake pc... otazkou na nase vedeni pak je, proc maji uklizecky na cipovych
> kartach maximalni opravneni???
To mi pripomina kamosovu historku z vypadkamy jedneho linux serveru.
Casom prisiel nato ze mu ho niekdo vytahuje zo zasuvky. Tak na zasuvku
napisal nevypinat a prelepil ju izolepou. O par dni nato bol svedkom jak
prisla upratovacka z kludom polarneho medveda izolepu odtrhla server
odpojila a zapla vysavac.
================================================================
Tato sprava obsahuje len stanoviska alebo informacie
odosielatela, ktore v ziadnom pripade nezakladaju pravny vztah
VUJE Trnava, a.s.
Stanoviska a informacie uvedene v tejto sprave sa nemusia
zhodovat s oficialnymi stanoviskami alebo informaciami
VUJE Trnava a.s.
This message contains only standpoints or informations
of sender, which in no case establish legal engagement
of VUJE Trnava, Inc.
Standpoints and information included in this message need not
be identical with the official standpoints or informations
of VUJE Trnava, Inc.
================================================================
---------------------------------------------------------------------------
Meta-FAQ (odhlášení, archív, FAQ a další): http://www.linux.cz/mailing-list
Milan Sorm
# > vypadek proudu nase ups a diesely ustoji, ale obcasnou navstevou zenske v
# > mzdovem tarifu jedna nebo dve s kostetem v ruce neodola ani sun, natoz
# > nejake pc... otazkou na nase vedeni pak je, proc maji uklizecky na
# cipovych
# > kartach maximalni opravneni???
#
# IMHO kvuli tomu, ze bezny admin se dostatecne casto popeli v prachu
# serverovny kvuli nejruznejsim sborkam a rozborkam. Kdyby mu nekdo pristrcil
# k ruce mop a vysavac s tim, ze ma uklidit vic nez jen "sve" stroje, tak by
# slo dotycnemu o zivot bez ohledu na jeho formalni postaveni ;-)
navrhoval jsem to u nas, ze si to klidne uklidim sam, ale pry z principu
holt uklizet musi uklizecka a admin musi adminovat a nejde to zamenovat.
jedina vyjimka: civilka muze uklizet, ale jinak nic.
--milan
---------------------------------------------------------------------------
Meta-FAQ (odhlášení, archív, FAQ a další): http://www.linux.cz/mailing-list
TIP: Prohledejte ftp.linux.cz: http://ftp.linux.cz/pub/
uh...@fantomas.sk
-> Tue, Jun 11, 2002 ve 07:03:13AM +0200 Zdenek Mazanec napsal(a):
-> # > vypadek proudu nase ups a diesely ustoji, ale obcasnou navstevou
-> # > zenske v mzdovem tarifu jedna nebo dve s kostetem v ruce neodola ani
-> # > sun, natoz nejake pc... otazkou na nase vedeni pak je, proc maji
-> # > uklizecky na cipovych kartach maximalni opravneni???
-> # IMHO kvuli tomu, ze bezny admin se dostatecne casto popeli v prachu
-> # serverovny kvuli nejruznejsim sborkam a rozborkam. Kdyby mu nekdo
-> # pristrcil k ruce mop a vysavac s tim, ze ma uklidit vic nez jen "sve"
-> # stroje, tak by slo dotycnemu o zivot bez ohledu na jeho formalni
-> # postaveni ;-)
-> navrhoval jsem to u nas, ze si to klidne uklidim sam, ale pry z principu
-> holt uklizet musi uklizecka a admin musi adminovat a nejde to zamenovat.
-> jedina vyjimka: civilka muze uklizet, ale jinak nic.
Ehm, vy asi nemate na hale vybavenie za miliony resp data za miliony, vsak?
namate vo vedeni nikoho kto vie pochopit ze predsa len upratovacka sa compom
nerozumie a ten to vie kde je co ake dolezite vie predsa len ovela lepsie,
kde si ma na co dat bacha?
--
Matus "fantomas" Uhlar, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I don't wish to receive spam to this address.
Varovanie: Nezelam si na tuto adresu dostavat akukolvek reklamnu postu.
"To Boot or not to Boot, that's the question." [WD1270 Caviar]
Robert Pospíchal
Měli jsem ve firme podobny problem, uklizecka se ochomejtla s kostetem kolem
serveru a bylo vystarano na dva dny. Reseni uklidu jsme pak vyresili
nasledovne, nechali jsme udelat ohromnou skrin, do které jsme nasledne
nahazeli veskerou techniku (svitche, kabelaz, servery, modemy...), skrin je
zamcena a klice mají jen admini a jedna slecinka, která ma pristup k
technice, když je potreba resit něco po telefonu. Funguje to skvele,
uklizecka uz nevytira prach vevnitr v pocitacich :).
---------------------------------------------------------------------------
Meta-FAQ (odhlášení, archív, FAQ a další): http://www.linux.cz/mailing-list
Ing. Pavel PaJaSoft Janousek
> kdo by se chtel vzeprit, je nemilosrdne napaden se slovy "vzdyt tady
> nemusite byt, jste tady stejne kvuli penezum"
Sorry, ale neudrzel jsem se, kdo je na VS quli penezum? Pravda, vsichni
quli vyplate, mzde apod. - ale quli penezum snad nikdo... (mozna si pod
tim pojmem predstavuju neco jineho...:-()
-----------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft) FoNet, spol. s r. o.
Vyvoj software, Intranet / Internet Sokolova 67, 619 00 Brno
E-mail: mailto:Jano...@FoNet.Cz Tel.: +420 5 4324 4749
SMS: mailto:P.Jan...@SMS.Paegas.Cz Fax.: +420 5 4324 4751
WWW: http://WWW.FoNet.Cz/ E-mail: mailto:In...@FoNet.Cz
-----------------------------------------------------------------------
---------------------------------------------------------------------------
Meta-FAQ (odhlášení, archív, FAQ a další): http://www.linux.cz/mailing-list
TIP: Konference o Perlu: perl na list...@muni.cz
Milan Sorm
# namate vo vedeni nikoho kto vie pochopit ze predsa len upratovacka sa compom
# nerozumie a ten to vie kde je co ake dolezite vie predsa len ovela lepsie,
# kde si ma na co dat bacha?
mame. ale na vysoke skole je nasledujici poradi dulezitosti:
vratny
uklizecka
udrzbar
byrokraticka referentka
vedouci referent
a pak klasicky akademicky zebricek
:)
kdo by se chtel vzeprit, je nemilosrdne napaden se slovy "vzdyt tady
nemusite byt, jste tady stejne kvuli penezum"
--milan
---------------------------------------------------------------------------
Meta-FAQ (odhlášení, archív, FAQ a další): http://www.linux.cz/mailing-list
TIP: Prohledejte nejprve archiv konference
Peter Ronai
>
> Měli jsem ve firme podobny problem, uklizecka se ochomejtla s kostetem kolem
> serveru a bylo vystarano na dva dny. Reseni uklidu jsme pak vyresili
> nasledovne, nechali jsme udelat ohromnou skrin, do které jsme nasledne
> nahazeli veskerou techniku (svitche, kabelaz, servery, modemy...), skrin je
> zamcena a klice mají jen admini a jedna slecinka, která ma pristup k
> technice, když je potreba resit něco po telefonu. Funguje to skvele,
> uklizecka uz nevytira prach vevnitr v pocitacich :).
>
V mojej byvalej robote sa mi stalo nieco podobne, ale spravil to sef ;)
Dosiel do coms room prehodit so mnou nejaku rec o comsi velice dolezitom
a ako ku mne prisiel, ja o 2 schody nizsie v chladenom racku po kolena,
nahodou kopol do vypinaca ....
dz
Milan Sorm
# Milan Sorm wrote:
# >kdo by se chtel vzeprit, je nemilosrdne napaden se slovy "vzdyt tady
# >nemusite byt, jste tady stejne kvuli penezum"
#
# Sorry, ale neudrzel jsem se, kdo je na VS quli penezum? Pravda,
# vsichni quli vyplate, mzde apod. - ale quli penezum snad nikdo... (mozna si
# pod tim pojmem predstavuju neco jineho...:-()
#
je zajimave, ze na VS se najdou lidi, kteri mi to tvrdi. taky to tady berou
jako hlavni duvod (vyse platu), proc by se tu meli mladi informatici udrzet.
je to trochu zvracene, ale mozna nekde ekonomicky software dela chybu zrovna
pri tisku me vyplatnice...
--m.s.
---------------------------------------------------------------------------
Meta-FAQ (odhlášení, archív, FAQ a další): http://www.linux.cz/mailing-list
TIP: Archivy news a prohledavani najdete na http://groups.google.com/