Přece jenom, v Pythonu 2 je toho tolik, co nikdo nebude přepisovat do Pythonu 3, že přinejmenším prodloužená podpora bude potřeba ještě hóóódně dlouho. Mimochodem pokud je to na třetích stranách, tak to může být docela výnosný trh.
Python 3 je výborný jazyk, mnohem koherentnější a "čistší", než Python 2. Škoda, že se nezlepšila podpora lambda výrazů, ta je i nadále dost ubohá a je to dle mého názoru hlavní nevýhoda Pythonu proti konkurenčnímu Ruby (které má samozřejmě zase svoje nevýhody). Ano, vím, proč to tak je a jaká logika je k tomu vede, ale to nic nemění na skutečnosti, že lambdy v Pythonu proste stojí za h0vno.
NB: Pokud člověk instaluje současně python 2 i 3 v Ubuntu 17.10, je ve výchozím nastavení "python" stále ještě 2.7.14.
Python má korutiny, to je mnohem zásadnější než lambdy (Ruby, přiznávám, neznám). Často člověk potřebuje spíš implicitní kontext než tvrdý paralelismus; je hrozně příjemné být schopen implementovat kooperativní multitasking čistě standardními prostředky jazyka. Jak by tohle zjednodušilo bare-metal embedded svět, kde buď volím mezi složitým FSM (tedy explicitním kontextem) nebo RTOS (což je často overkill).
Lambdy jsou anonymní funkce, s korutinami ani paralismem nijak přímo nesouvisí. Jsou ideální pro parametry funkcí vyšších řádů, různé filtry, iterátory apod., a samozřejmě i pro zpětná volání. Ruby má plnou podporu lambd, v Pythonu jsou "ořezané" na jeden jediný výraz. Python to částečně dohání tím, že dovoluje lokální vnořené funkce, ale i tak mi to příjde jako zbytečný opruz.
Ruby obecně je velmi podobný jazyk, jako Python, ale trošku říznutý Perlem. V praxi se používá hlavně v souvislosti s frameworky Rails (webové aplikace) a Metasploit (exploity a pen testing).
Ruby rozhodně není mrtvola. Není tolik rozšířený, jako Python, ale nicméně má velmi aktivní komunitu a ve svých oborech je silně zakořeněný. A na rozdíl od JavaScriptu jsou Ruby i Python inteligentně promyšlené.
kooperativní multitasking jde snadno implementovat i v pythonu 2. vystačíte si s yield, send a next. Ostatní je jen cukr.
pro mínusáře PEP342 -- Coroutines via Enhanced Generators
funguje to v pythonu 2.5 a novejsim
Přesně tak, Py3 je supr jazyk, ale popularita Py2 byla již v době forku podle mě podceněna a rok 2020 rozhodně nevyjde.
Článek je výborné shrnutí se zajímavými odkazy, díky, autore!
V Py2 běží taková spousta kritických, velkých nebo naopak skrytých věcí, že je to neštěstí. Psané byly v době, ze které si ještě spousta manažerů pamatuje, jak jim kluci ajťácký slibovali, že ten nový neznámý jazyk je naprosto geniální a mají k němu svolit.
Používat v IT věk nějakého nástroje jako důvod jeho změny nepovažuju za dostatečný argument. Měli bychom si naopak vážit tradice, kompromisně s pokrokem.
Jen taková poznámka - Python je starší než Java. A hrabat se v 10 let starých zdrojácích v ní taky není něco extra :)
Neni to nic extra, ale kod (i bytecode) z Java 1.0 bezi uplne stejne na Java 10 jako tehdy a proto se nikdo moc ve zdrojacich hrabat nemusi.
Se všemi nevýhodami, které to s sebou nese. Třeba type erasure u generik. Oba přístupy jsou "správné" a ani jeden není univerzálním řešením všeho.
Upřímně, raději skousnu type erasure, než při upgradu JVM řešit zásadní nekompatibility, hlavně knihoven třetích stran.
Python se zjevně rozpadá na 2 jazyky. Ne každý je nadšený z Pythonu 3, viz třeba http://lucumr.pocoo.org/2011/12/7/thoughts-on-python3/ - taky na to narážím.
Něco zůstane v Py2, něco bude jen v Py3. Oblíbenosti Pythonu to neprospěje.
Prosím tě, ten článek, co odkazuješ, je 6 let starý a týká se v podstatě ještě experimentální verze 3.2. Ano, tehdy byla představa, že vše automaticky vyřeší nástroj 2to3, a od té doby (v dalších verzích) přibyly do Pythonu 3 konstrukce umožňující psát jeden kód běžící v Pythonu 2 i 3.
Vše, co ten člověk (a skupina okolo něj) napsal - Flask, Click..., samozřejmě bez problému běží na Pythonu 3.
Hmm ... článek z roku 2011 ...
Armin Ronacher - autor toho blogu - Python3 používá a podle githubu s ním nemá větší problémy ...
Nejen názory, ale i Python3 se vyvíjí
Armin Ronacher tak trochu přechází na Rust.
Jasně, přechází! Zrovna letos měl na PyCon CZ v Praze o Rust přednášku :)
https://www.youtube.com/watch?v=zmtHaZG7pPc
Tam jsem byl osobne. Ale porad nevim, co to rika k puvodnimu tematu.
Lide kteri nemeni nazory se situaci, jsou odsouzeni evoluci k vyhynuti.
@ haha (neregistrovaný) ---.nfa.cz .... to jsou oportunisté, kam vítr tam plášť, ti přežijí všechno :-)
Konečně po dlouhé době snad dvojková řada zemře, vždycky si říkám, proč musím mít v systému dvě verze, když trojku máme už strašně dlouho ... BTW pánové z Redhatu budou mít docela veselo, dlouhou dobu REHL Python 3 vůbec nepodporoval a teď to budou muset do dvou let stihnout odladit.
Ještě se zbavit GIL a z Pythonu bude velice zajimavy jazyk
Python 2 za 2 roky nezemre. Podpora prodlouzi bud samotna PSF nebo nejaky fork.
„Věřím, že Python 2 bohužel zůstane v repozitářích ještě velmi dlouho potom, co ho usptream „zabije“.“
Nic proti pokroku, ale není nic lepšího, než po letech vyhrabat starý projekt (ať už svůj, nebo na netu), který nemá alternativu a pak hodiny trávit snahami jej vůbec spustit.
Zrovna nedávno jsem hledal jednu „historickou“ informaci a narazil jsem na starý archiv jednoho webu, který měl databázi v SQLite (ach, ty začátky). Problém byl v tom, že to byla jakási stará, dnes nepodporovaná verze. Po nějaké době jsem to vzdal a začal přemýšlet, na co ty archivy vlastně mám. Resp. jestli bych k těm archivům neměl přidávat i kopii systému.
Software je živý organismus, archivovat se nedá, rychle podléhá zkáze. Ale to není nic proti ničemu, když pekař upeče chleba, taky se za 14 dní nedá jíst.
Ne, software neni zivy organismus, stejne jako jim nejsou matematicke postupy, pisen nebo basen. Ta analogie s pecivem je zcela mimo.
V (tuším) IEEE explore byl před časem článek o digitální archivaci. Jak to je velký problém i pro velké firmy. Hezký byl případ Pixaru, který měl sice zalohovane úplně všechno na co přišli, ale zapomněli si uložit seed pro rng. Následek toho byl, když chtěli dělat remaster, tak tráva nebo řasy se jim hybala úplně jinak a oni tedy (IIRC) museli platit animatory, kteří ta stébla animovali ručně.
Týká se filmu "finding Nemo", nějak mi to vypadlo z textu.
"...a pak hodiny trávit snahami jej vůbec spustit."
toto riesi kontajner ala docker, ak by si ludia zvykli svoj soft nasadzovat alebo archivovat ako docker image....
Ja v pythonu nenapsal ani radku kodu nicmene par utilitek napsanych v pythonu pouzivam. Otazky tedy zni:
- Je problem spustit P2 kod v P3 interpreteru, je tam zpetna kompatibilita ?
- Nakolik je P3 nekompatibilni s P2?
- nejaka automaticka konverze kodu P2->P3 je problem ?
- Je problem spustit P2 kod v P3 interpreteru, je tam zpetna kompatibilita ?
Kód musí používat jen konstrukce validní v obou verzích, pak to fungovat bude.
- Nakolik je P3 nekompatibilni s P2?
Trochu jiná povolená syntax, občas přejmenované knihovny, jiné vnímání stringů a bytů atd.
- nejaka automaticka konverze kodu P2->P3 je problem ?
Existují nástroje pro konverzi, ale zkonvertovat sémantické změny je obecně problém, který se musí řešit manuálně.
V obecném případě není možné psát kód, který by fungoval v obou. Těch nekompatibit je poměrně dost a jdou od trivialit ("print" je příkaz v py2 ale v py3 je to knihovní funkce apod) až po zásadní rozdíly: řetězce v py3 jsou v utf8, jiné metatřídy atd
Není to obvykle problém, když se ví co s tím. Např:
from __future__ import print_function
print("Hello World!")
je funkční v Python 2 i 3...
Více třeba zde: https://wiki.python.org/moin/PortingToPy3k/BilingualQuickRef
To ale přidává podporu některých věcí z 3 do 2. A 2 končí.
>Zásadním problémem, který zatím nikdo příliš neřeší, je závislost na Pythonu 2 pro různé build skripty programů, které napsané v Pythonu vůbec nejsou.
Mohu potvrdit. S tím bude třeba mít dost zásadní problém macOS.
Tam se v instalačních skriptech může používat cokoliv a Python se používá opravdu velmi často.
Bohužel Apple ve výchozí instalaci dodnes Python 3 vůbec nemá, ani jako alternativu :-(
Na druhou stranu ty instalační sktipty jsou většinou dost jednoduché, takže by mohli být s Pythonem 3 kompatibilní.
Jo, jednu dobu som mal na jablku ako default interpreter python3 pod symlinkom python a ani raz som nenarazil na problem.
Vzhladom k tomuto pristupu vyvojarov Pythonu je jedinym rozumnym "Co robit" utiect co najdalej a uz nikdy na nic, co nejak suvisi s pythonom, nesiahat.
Cely tento bordel sposobili prave ludia za Pythonom a ani dnes, skoro 10 rokov po vydani, sa Py3 neda pokladat za funkcnu alternativu.
Můžu vědět, z jakého důvodu se nedá Python 3 považovat za funkční alternativu? Souhlasím s tím, že vydat zpětně nekompatibilní verzi se ukázalo jako veliký problém a dost možná to byla chyba. Ale Python 3 je lepší jazyk než Python 2 a nechápu proč by to neměla být funkční alternativa.
Pretoze nech sa clovek snazi "naportovat" cokolvek, narazi aspon na jednu kniznicu, co py3 nepozna :(
To přece ale nesouvisí s jazykem. Navíc to není pravda (což jde matematicky dokázat uvedením protipříkladu, případně sporem).
> To přece ale nesouvisí s jazykem.
Je to dane prave tou spatnou nekompatibilitou jazyka.
> což jde matematicky dokázat uvedením protipříkladu, případně sporem
Len ak by sa Vam podarilo urcit, ktoreho konkretneho cloveka som mal na mysli :)
Co Jython? Ten asi umira porad v rezimu kompatibility s CPython 2.x ze? Asi to nebude vetsi problem, ale mit Python i na JVM me prislo fajn (kdyz uz maji .NETaci zeleznej python).
Vývoj Jythonu se tak nějak zdá se moc dopředu neposouvá. Relativně nedávno se podařilo z 2.5 dostat na 2.7. O trojce se už delší dobu mluví, ale o ničem konkrétním zatím nevím. (Ten projekt ale nesleduju příliš pozorně.)
No tohle autor článku asi trochu přehnal. Ono datum 1.1.2020 bylo stanoveno jen aby tam nějaké datum svítilo, ale ve skutečnosti to datum není definitivní a nejspíš se zase o pět let posune. Vývojáři jeho podporu ukončit nehodlají, tedy aspoň co jsem zatím četl jejich vyjádření.
Článek je ozdrojovaný a protkaný odkazy. Pokud máte jiné informace (taktéž podložené odkazy a zdroji), rád se nechám poučit. BTW o 1.1.2020 v článku není ani slovo.
Omg, chtit po nem zodkazovat spekulaci je stejny nesmysl jako kdysi, ze 2015 bude definitivni EOL.
AFAIK oficialni termin ke konkretnimu dni nebyl stanoven, odhaduje se duben 2020. Vytykat domenku, ze to bude uz k 1.1. je stejne hloupe jako obhajovat libovolny den v tomto roce.
Měl jsme na mysli „Vývojáři jeho podporu ukončit nehodlají, tedy aspoň co jsem zatím četl jejich vyjádření.“ - pokud takové vyjádření někde existuje, tak bych ho rád viděl. Neříkám, že neexistuje, jen, že o něm nevím.
No honem nenacházím rozhovor nebo konverzaci mezi vývojáři, ale k tomu 1.1.2020 je to v ofiko dokumentaci a tam je to celkem hezky řečené: https://devguide.python.org/#status-of-python-branches
Ten autor mi prijde docela fundamentalisticky -- a zbytecne.
Ten PEP rika
```
It is anticipated that there will eventually come a time where the third party ecosystem surrounding Python 3 is sufficiently mature for this recommendation to be updated to suggest that the python symlink refer to python3 rather than python2.
```
ale soucasne rika i
```
If the Python 2 interpreter becomes uncommon, scripts should nevertheless continue to use the python3 convention rather that just python. This will ease transition in the event that yet another major version of Python is released.
```
Cili ciste teorieticky nic nestoji v ceste tomu, aby python (bez cisla verze), vyhynul nebo byl navzdy spojen s pythonem 2.x. Zjednodusilo by to potom skriptovani.
Bohuzel tato fundamentalisticka preznacovaci manie v distribucich (cimz je jiz ocividne nakazeny i redhat a fedora) ma za nasledek, ze dneska neexistuje python 2.7 shebang, ktery by fungoval vsude -- python je v ArchLinuxu defaultne python3 (navzdory tomuto PEP, ale to muze byt problem soubehu), s python2 mame zase v nasem projektu problemy s MacOS X, protoze ten symlink se standardne nevytvari (a pravdepodobne i nekde jinde, ale ted si nevzpomenu).
> Jsem fundamentalistický.
Ja bych to definoval jako aktivni kokot.
Jinak zbezna prohlidka vaseho verejneho repa na githubu je dost zklamani, same sranda-projekty na urovni krouzku programovani pri zakladni skole. Tyka se jen vlastnich, na forky jsem se nedival.
Celkem to zapada do obvykleho obrazu prumerneho az podprumerneho, ktery se musi hlasiteji ozyvat aby tak kompenzoval nedostatek talentu. Sorry za prikrost..
Zcela zbytečné a ničemu neprospivajici, natož pak celkové úrovni diskurzu.
Nahodou ten clanek dobre upozornuje napriklad na to, aby si lidi prohlidli svoje projekty a treba se konecne dokopali k tomu, aby to prepsali do trojky. Mam pocit, ze presne toto ti vadi (udrzba stareho projektu, kterej se vsichni boji obracet i vidlema?), proto osocujes autora, ktery ma sve tvrzeni skutecne dobre ozdrojovane.
Mate pravdu, Miroslav je pro mne dost velke zklamani.
Jeden by cekal ze v Pythonu 2 uz ani nikdo nedela, ale tady pan autor ma potrebu si neco clankem dokazovat a tancit na hrobu teto ubohe technologie. Typicky obraz prumerneho az podprumerneho aktivniho clena Python komunity, ucitele, a organizatora, ktery se i pres zjevnou nesmyslnost tohoto chovani musi hlasite ozyvat, aby pomohl tem slabsim a pomalejsim s nedostatkem talentu, aby na Python 3 uz konecne presli.
Prosimvas, ani tady o tom radeji nediskutujte. Venujte se necemu uzitecnemu! Kdybyste radeji uklidili odpadky pred domem nebo posbirali nejaka vicka pro deti v krouzku programovani pri zakladni skole.
Sorry za forky, mam poruchu osobnosti.
Ukaž nám vlastní github ty ženský orgáne :D
> python je v ArchLinuxu defaultne python3 (navzdory tomuto PEP, ale to muze byt problem soubehu), s python2 mame zase v nasem projektu problemy s MacOS X, protoze ten symlink se standardne nevytvari (a pravdepodobne i nekde jinde, ale ted si nevzpomenu).
V tomto pripade je najjednoduchsie Arch proste ignorovat, jeho vyvojari a packageri si uz na pustanie sed-u nad pythonimi balickami davno museli zvyknut :)
To take v zásadě děláme, akorát nám pak na githubu pravidelně někdo otevírá pr měnící shebang python na python2 a my je pravidelně zavirame jako wontfix. Akorát že pak dochází k různému mrzeni na straně contributora a pak i na naší.
Viděl jsem projekt (nemůžu si teď vzpomenout jaký), kde u toho shebangu byl vysvětlující komentář, ať to lidi nedělají (a proč).
Řešením je používat mechanismus entrypoints ze setuptools a žádné shebangy vůbec v projektu nemít.
To funguje len pri niecom, co sa instaluje, nie pri skripte, ktory sa ma nakopirovat a bezat. Napriklad s tym mali (maju?) problem hry napisane v RenPy.
Ja nastastie MacOS podporovat nemusim, ale pamatam si rozhodovanie medzi podporou Archu a starsieho Ubuntu :)
kdyz pouzivas Python, tak vzdy pamatuj:
abys mel na vsech servrech u vsech zakazniku nainstalovany vsechny verze Pythonu
Pozor, i mezi desetinkovými verzemi Pythonu je rozdíl ... viz např. pořadí složek v slovníku v 3.něco vs vyšší! Je spousta detailů které ti můžou rozhodit knihovnu nebo aplikaci. A třeba některé knihovny jako Qt nepodporují 3.6...
Tak ja sem zvyklej z verze dve na vicemene nahodny poradi klicu v dictionary, takze tohle bych fakt neresil, ani kdybych trojku pouzival, jako ze k tomu nevidim moc duvod...
Tak tohle je buď vaše chyba, že závisíte na nespecifikovaném chování, a nebo chyba specifikace pythonu, že něco naspecifikuje a pak to změní. Já sázím, na první variantu. Bohužel programovat stylem "mě to tu běží" neznamená programovat správně. Nespecifikované (nebo nedefinované) chování je právě určené k tomu, aby mohl kompilátor nebo interpret zvolit rychlejší implementaci, pokud ji někdo vymyslí.
Já jsem zvyklý, že pořadí klíčů ve slovníku může být jiné dokonce při každé iteraci slovníkem. (To vyplývá i z jednoduché implementace slovníku například hashovou tabulkou. Jednoduchá implementace hashové tabulky řeší kolizní klíče spojovým seznamem. Odebrání a přidání klíče pak může tento klíč v tomto seznamu posunout na jiné místo). Dokonce i když vytvoříte dva slovníky stejným způsobem, může mít každý klíče v jiném pořadí. Do hashovací funkce lze totiž přimíchat například adresu slovníku v paměti, právě proto, aby byla menší pravděpodobnost, že dojde k hashovým kolizím právě na stejných klíčích.
"Tak tohle je buď vaše chyba... " Jaká chyba, já o chybě nikde nepíšu... je že se mění specifikace i s desetinkovou verzí -- pokud je to interpretovaný jazyk, pak může nastat občas problém.
nemenila se specifikace kde je ze poradi klicu je v Dict nahodne/nezarucene . Ale implementace. V pripade ze jste mel kod zavisly na implementaci tak to potez.
Jinak ..pokud chci serazeny slovnik .. existuje 'OrderedDict'
As of Python 3.7, this is no longer an implementation detail and instead becomes a language feature.
... Pokud programuji oproti verzi 3.6 a větší nad CPythonem, tak nevím proč bych nemohl záviset i na implementačním detailu. Stejně spousta programů závisí na gcc a nějaké specifické feature.
"nevím proč bych nemohl záviset i na implementačním detailu"
Tak tahle diskuze rika dost jasne proc bys nemel zaviset na implementacnim detailu... Muze se verze od verze a implementace od implementace lisit, cili kod pak neni prenosnej.
Přenosný v jakém smyslu? Programujeme oproti CPythonu a většinou na nejnovější verzi --- ano takový luxus si dopřáváme. Je to stejný jako když si řeknete, že programujete v C++17 a basta.
Prenosny ve smyslu, ze to nemusis prepisovat s kazdou novou verzi ci pri prechodu na jinou implementaci...
Já se nechci hádat, určitě nedoporučuji spoléhat na "ledajaké" implementační detaily -- ale popravdě, většina jede na CPythonu, minimum na PyPy -- které navíc právě se trojkou nepočítá, a pokud píšu interní knihovny a můžu si určit, že jedeme na Pythonu 3.7 a více, tak nevidím problém. Ostatně třeba requests podporují až Python 3.3 (release 2012) a viděl jsem knihovny které mají 3.5+; kvůli čemu myslíte, že nepodporují starší desetinkové verze?
PyPy is a fast, compliant alternative implementation of the Python language (2.7.13 and 3.5.3).
Od 3.7 je prostě dict zachovává pořadí, bude to standard a nemusíme používat OrderectDict, dost velká výhoda při zpracování **kwargs nemyslíte? Minimálně to nikdo nezapomene.
Jinak vlastně souhlasím: je to moje chyba, pokud nečtu specifikaci... znát ale dokonale specifikaci je nemožné, naštěstí python nemá až tak moc temných zákoutí -- a většina blbostí z neznalosti se odchytí testem.
clanek a diskuse je o Pythonu, ne o PHP, i kdyz oboje zacina na 'p'
Já pořád používám Python 2.x, někde dokonce jen verzi 2.5, které také už nikdo nepodporuje. A nehodlám na tom nic měnit. Není to konec řady 2, je to nový začátek stabilní řady 2, které už nebude podléhat změnám.
Pro vlastní použití je to jedno. Ale pokud něco dodáváš platícímu klientovi, nevadí mu, že se mu to bude tvůj kód stále obtížněji upgradovat, až ho jednoho dne zahodí kompletně nebo přepíše do trojky?
Proc by mel muj kod stale obtizneji upgradovat? Upgradívat pujde porad stejne. Neni duvod, aby ho zahazoval a prehazoval do trojky. Neznas prislovi neopravuj co funguje? Muj klient bez problemu pouziva dokonce i programy pro win16 a to uz je porna historie. Jsou to programy pro cteni dat z jistych mericich serveru. A dokud tyto pobezi, bude pouzivat i tyto programy.
Python 2.5 i Python 2.6 kupříkladu neumožňuje používat TLS 1.2 - ne že by to nešlo v principu, ale ten opruz s předěláním střev za to nestojí. Relativně nedávno to ještě nikoho až tolik netrávilo, ale nepřeju nikomu, aby něco podobého musel řešit u Pythonu 2.7, až bude definitivně zastaralý. Přechod z 2.5 na 2.7 byl legrace, ale dělal jsem ho na jednom systému také za všeobecného pocitu, že 2.5 je pořád v klidu. No, nebyl.
Na tohle se často hodí použít requests místo urllib a nechat SSL/TLS na proxyně. My jsme to tak udělali abychom mohli nechat dožít software běžící ještě na debianu Lenny (10 let stará distribuce), který stahuje něco po https od externího dodavatele (který mezitím přešel na certifikáty, které takhle starý stroj podporovat nikdy nebude). Jako proxy jsme použili Apache, protože ten rozumí proxy požadavku "GET https://foo.bar.baz/url", zatímco Squid (který (z historických důvodů) používáme) protokol 'https' v GETu nepodporuje. Výhoda je, že starý software není potřeba aktualizovat kvůli SSL protože SSL řeší nový software na jiném stroji.
Nic proti SSL proxy, ale já jsem jednak řešil už hotový rozsáhlý systém a jednak šlo o klientskou stranu spojení.
Tak prosím tě s tímhle přístupem si hlavně programuj do šuplíku a neopovažuj tím zamořovat github nebo ještě hůře někomu to prodávat.
Nech si svoje detinske rady pro sobe rovne. Dekuji.
Už jsme chtěli několikrát přejít na python3, ale bohužel tam stále není nic by bylo tak skvělé a zaplatilo by to ten drahý přechod a zpomalení aplikace okolo 20-30%. Pokud se Python3 razantně zrychlí a začnou řešit reálné problémy místo, tak se to možná změní.
Jinak mimochodem to, že je spousta projektů převedená na python3, neznamená, že by se python3 používal, spíše více vývojářů, kteří dělali větší projekty v pythonu odchází, jelikož jim to za to nestojí.
Jestli tě čeká zpomalení o 30% tak máte ten kód dost zprasený. Za to ale nemůže python.
Německý federální soud v poslední instanci rozhodl, že firma Eyeo, která stojí za Adblock Plus, nepoškozuje vydavatelství Axel Springer…
Andrey Meshkov, zakladatel společnosti Adguard objevil v Google Chrome Store pět falešných rozšíření, která slibovala blokování reklamy, ale…
Monitorovací systém vám umožní dozvědět se o problémech ve vaší síti ještě dříve, než se projeví. Místo „hašení problémů“ jim tak můžete…
Informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2018 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.
Při poskytování služeb nám pomáhají cookies. Používáním webu s tím vyjadřujete souhlas.