Od 3. listopadu 2025 budou muset nová rozšíření Firefoxu specifikovat, zda shromažďují nebo sdílejí osobní údaje. Po všech rozšířeních to bude vyžadováno někdy v první polovině roku 2026. Tyto informace se zobrazí uživateli, když začne instalovat rozšíření, spolu s veškerými oprávněními, která rozšíření požaduje.
Jste nuceni pracovat s Linuxem? Chybí vám pohodlí, které vám poskytoval Microsoft, když vás špehoval a sledoval všechno, co děláte? Nebojte se. Recall for Linux vám vrátí všechny skvělé funkce Windows Recall, které vám chyběly.
Společnost Fre(i)e Software oznámila, že má budget na práci na Debianu pro tablety s cílem jeho vyžívání pro vzdělávací účely. Jako uživatelské prostředí bude použito Lomiri.
Proběhla hackerská soutěž Pwn2Own Ireland 2025. Celkově bylo vyplaceno 1 024 750 dolarů za 73 unikátních zranitelností nultého dne (0-day). Vítězný Summoning Team si odnesl 187 500 dolarů. Shrnutí po jednotlivých dnech na blogu Zero Day Initiative (1. den, 2. den a 3. den) a na YouTube.
Byl publikován říjnový přehled dění a novinek z vývoje Asahi Linuxu, tj. Linuxu pro Apple Silicon. Pracuje se na podpoře M3. Zanedlouho vyjde Fedora Asahi Remix 43. Vývojáře lze podpořit na Open Collective a GitHub Sponsors.
Iniciativa Open Device Partnership (ODP) nedávno představila projekt Patina. Jedná se o implementaci UEFI firmwaru v Rustu. Vývoj probíhá na GitHubu. Zdrojové kódy jsou k dispozici pod licencí Apache 2.0. Nejnovější verze Patiny je 13.0.0.
Obrovská poptávka po plynových turbínách zapříčinila, že datová centra začala používat v generátorech dodávajících energii pro provoz AI staré dobré proudové letecké motory, konvertované na plyn. Jejich výhodou je, že jsou menší, lehčí a lépe udržovatelné než jejich průmyslové protějšky. Proto jsou ideální pro dočasné nebo mobilní použití.
Typst byl vydán ve verzi 0.14. Jedná se o rozšiřitelný značkovací jazyk a překladač pro vytváření dokumentů včetně odborných textů s matematickými vzorci, diagramy či bibliografií.
Specialisté společnosti ESET zaznamenali útočnou kampaň, která cílí na uživatele a uživatelky v Česku a na Slovensku. Útočníci po telefonu zmanipulují oběť ke stažení falešné aplikace údajně od České národní banky (ČNB) nebo Národní banky Slovenska (NBS), přiložení platební karty k telefonu a zadání PINu. Malware poté v reálném čase přenese data z karty útočníkovi, který je bezkontaktně zneužije u bankomatu nebo na platebním terminálu.
V Ubuntu 25.10 byl balíček základních nástrojů gnu-coreutils nahrazen balíčkem rust-coreutils se základními nástroji přepsanými do Rustu. Ukázalo se, že nový "date" znefunkčnil automatickou aktualizaci. Pro obnovu je nutno balíček rust-coreutils manuálně aktualizovat.
Narazil jsem v diskuzích všude možně na jeden podivný jev: hrozivá a všudypřítomná averze k nástroji ip a nesmyslné preferování programu ifconfig, ačkoli je označen za "zbytečný" snad někdy od roku 1999. Přitom program ip má tak přirozenou syntaxi!
Legenda (celé je to dost široké, skryjte si proto levý sloupec):
IFACE interface, např. eth0, eth1 atd. IPADDR/PREFIX adresa sítě (u rout) nebo "brány" / prefix, např. 192.168.0.1/24 apod. IPADDR IP adresa, např. 12.34.56.78 NUM nějaké číslo, např. 1, 20, 300 apod. + speciální znak, viz `man ip'
A mluvíme, mluvíme:
nahoď "bránu" sítě IPADDR/PREFIX s broadcastem IPADDR na interface IFACE ip address add IPADDR/PREFIX broadcast IPADDR dev IFACE nahoď "bránu" sítě IPADDR/PREFIX s broadcastem na interface IFACE ip address add IPADDR/PREFIX broadcast + dev IFACE nahoď "bránu" sítě IPADDR/PREFIX s broadcastem jako IFACE:NUM na interface IFACE ip address add IPADDR/PREFIX broadcast + label IFACE:NUM dev IFACE odeber "bránu" sítě IPADDR/PREFIX z interfacu IFACE ip address delete IPADDR/PREFIX dev IFACE routuj síť IPADDR/PREFIX přes IPADDR ip route add IPADDR/PREFIX via IPADDR routuj síť IPADDR/PREFIX na interface IFACE ip route add IPADDR/PREFIX dev IFACE odstraň routu IPADDR/PREFIX ip route delete IPADDR/PREFIX
Přijde ještě někomu teď syntax programu ip nelogická? Samosebou lze zkracovat, takže například místo ip address delete ... lze napsat třeba ip a del ..., slovo broadcast lze krátit na pouhé brd a podobně. Nástroj ip toho umí samosebou mnohem více, než jsem zde bylo ukázáno, ale vždy je jeho syntax taková, že si připadáme skoro jako bychom mluvili.
Tím jsme snad rozbili argumenty škarohlídů, kteří tvrdí, že ip ma nelogickou syntax a přejděme k druhé, daleko závažnější části tohoto příspěvku.
Další věcí je zcela jasný argument proti programu ifconfig, který ukáži na ukázkach. Totiž, že na jednom interfacu může být nahozených vícero adres je snad nad slunce jasné. Mluvme tedy třeba takto:
ip a add 192.168.0.1/24 brd + dev eth1 ip a add 192.168.0.2/24 brd + dev eth1 ip a add 192.168.0.3/24 brd + dev eth1
A nyní se podíváme, jestli se nějak budou lišit výpisy příkazů ifconfig a ip:
ifconfig eth1
eth1 Link encap:Ethernet HWaddr 00:01:02:03:04:05
inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
... atd.
Už na první pohled je jasné, že tu něco nehraje. Program ifconfig nám totiž vypsal pouze první síť 192.168.0.1/24 a ostatní jako by ani neexistovaly! Naproti tomu program ip nám vše vypíše správně:
ip a show dev eth1
2: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:01:02:03:04:05 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.1/24 brd 192.168.0.255 scope global eth1
inet 192.168.0.2/24 brd 192.168.0.255 scope global secondary eth1
inet 192.168.0.3/24 brd 192.168.0.255 scope global secondary eth1
... atd.
Aby nám program ifconfig vypisoval správně, museli bychom explicitně použít deklaraci label při nahazování programem ip, to jest např. takto:
ip a add 192.168.0.1/24 brd + label eth1:1 dev eth1 ip a add 192.168.0.2/24 brd + label eth1:2 dev eth1 ip a add 192.168.0.3/24 brd + label eth1:3 dev eth1
Pak by nám i příkaz ifconfig vypsal vše jak má.
Z uvedeného však bohužel jasně vyplývá, že přinejmenším pro zjišťování stavu interfaců se program ifconfig nehodí! Naproti tomu program ip vypíše správné informace i v případě, že jsme adresy nahazovali na interface pomocí příkazu ifconfig. A používat na nahazování sítí jeden nástroj a na vypisování druhý - no nebylo by to takříkajíc poněkud "na hlavu"?
Proto se důrazně nedoporoučuje používat dnes již naprosto nevyhovující a v Linuxu již dávno nepodporovaný nástroj ifconfig a naopak přísně doporučuje naučit se mluvit k našemu systému skrze logickou syntax programu ip. A věřte mi, že se mi ten manuál číst také nejdřív moc nechtělo, ale dnes blahořečím dni, kdy jsem do terminálu napsal man ip.
Tiskni
Sdílej:
.
Bohužel sám mam máslo na hlavě, jelikož na jednoduché nastavení sítě ze zvyku taky ifconfig používam (něco jako "ifconfig eth0 192.168.0.1 netmask 255.255.255.0"). Ale je to opravdu jen zlozvyk, na cokoliv složitějšího (nastavení route, IPv6, tunelů, atp.) používam ip.
ifconfig eth0 192.168.0.1 netmask 255.255.255.0Tak presne tohle me donutilo zacit pouzivat iproute2. Jak ja jsme liny psat sitove masky!
ifconfig úplně jinou syntaxi i logiku (bližší iproute2 a realitě), přestože jeho advokáti se nás snaží přesvědčit, že ta původní byla lepší…
ifconfig eth0 192.168.0.1 netmask 255.255.255.192
hej?
když seš línej, tak ji nepiš, maska 255.255.255.0 je totiž default ... jinak nevím jak u tebe, ale u mě zvládá ifconfig notaciifconfig eth0 192.168.0.1 netmask 255.255.255.0Tak presne tohle me donutilo zacit pouzivat iproute2. Jak ja jsme liny psat sitove masky!
192.168.0.1/24
A co treba nejaky port?
ip má manuálovou stránku. Mně se totiž nějak nenainstalovala a neviděl jsem ji třeba ani v Debianu. Našel jsem ji až u zdrojáků.
ip -6 ro add 2001:6f8:967:1::/64 dev eth1
ifconfig se chová, jako by skutečně existovalo samostatné virtuální rozhraní eth0:0 a při pokusu pracovat s ním (např. nastavit mu příznaky) pracuje ve skutečnosti s rozhraním eth0. Zejména kombinace s tím, že ifconfig nedostatečně rozlišuje mezi "rozhraní je UP" a "rozhraní má přiřazenu adresu", může věci neznalého uživatele "kousnout do zadku"…
ifconfig
ifconfig v Linuxu nefunguje, pouze je tam (nepříliš dokonale) emulován. Ten zásadní problém není v nepřehledné a chaotické syntaxi, ale v tom, že ifconfig je založen na jiné koncepci síťových rozhraní, než jaká je interně použita v jádře. A to prostě nemůže dělat dobrotu - a také nedělá.
S oblibou to přirovnávám k tomu, kdybyste chtěl pro konfiguraci paketového filtru používat emulaci ipchains (nebo ještě spíš ipfwadm, který také patří k jádru 2.0). Pár jednoduchých příkladů vám bude fungovat, ale jakmile narazíte na mantinely té emulace, máte problém. Je velmi nešťastné, že zatímco u ipchains to většina lidí chápe, spousta (jinak docela informovaných) uživatelů Linuxu se pořád zoufale zuby nehty drží emulovaného ifconfigu a tvrdošíjně odmítá používat nativní nástroje.
A to nemluvím o neustále se opakujících dotazech, které sice jsou naprosto nesmyslné, ale tazatelům se zdají zcela přirozené, protože mají zcela chybnou představu o fungování síťových rozhraní. Představu, kterou v nich vzbudili autoři dokumentace, kteří žijí (jako vy) v přesvědčení, že pro jejich potřeby ifconfig prostě funguje a víc je (ani jejich čtenáře) zajímat nemusí. Namátkou např.:
iptables nechce vzít podmínku '-i eth0:0'?eth0:0?
eth0 a eth0:0 jinou MAC adresueth0:0 neexistuje, pouze ifconfig a nezodpovědní autoři dokumentace vás utvrzují v mylné představě že ano.
ifconfig a ip si nemohou vymýšlet svou koncepci jen tak, jak je napadne. Oba totiž fungují jen jako user space rozhraní pro konfiguraci driverů jádra. Takže je podstatné, jak jsou síťová rozhraní implementována v jádře, na tom chtě nechtě musíte stavět. Příkaz ifconfig to nerespektuje, protože je postaven na koncepci, která byla ve starších verzích jádra (do řady 2.0). Příkaz ip vychází z koncepce, která tam je teď.
To, že když pomocí ifconfig zkusíte změnit parametry rozhraní eth0:0, změní ve skutečnosti parametry eth0, je prostě něco víc, než jen nějaká "jmenná koncepce". Sice není to chyba příkazu samotného, ale je to chyba toho, kdo ho používá v prostředí, pro které nebyl navržen a pro které se nehodí. Až si jednou v domnění, že odstraňujete druhou IP adresu, sestřelíte interface, přes který jste připojen na vzdálený počítač, třeba ten rozdíl uvidíte v jasnějších barvách.
A to, ze je neco nejak v Linuxu naimplementovano, neznamena, ze to je to spravne a vse ostatni je treba vyhladit
Ne, samozřejmě ne. Nikdo ovšem netvrdí, že se nemá ifconfig používat tam, kde je nativním nástrojem a kde interní implementace jádra odpovídá jeho koncepci. Naopak, tam je na místě ifconfig použít. Ale pokud je v Linuxu implementace jiná, je chybou snažit se tam roubovat ifconfig, který je s ní nekompatibilní. Nebo si snad myslíte, že by bylo správné snažit se na Windows XP implementovat příkaz iptables k nastavování jejich paketového filtru, který je postaven na úplně jiných principech, jen proto, že jste na něj z Linuxu zvyklý?
Samozřejmě je možné, že v některé z budoucích vývojových řad dojde k zásadnímu přepracování koncepce síťových rozhraní, takže nebude odpovídat koncepci iproute2. Pak bude ip stejně obsolete jako dnes ifconfig a spol. a bude stejnou chybou snažit se ho uměle roubovat na nové systémy. Takže iproute2 není Jedině Správné Řešení, ale je to jediný správný nástroj pro konfiguraci síťových rozhraní v linuxových systémech s jádry řady 2.2 až 2.6 (zatím).
Proc bych nemohl, kdyby to pro mne melo smysl, implementovat mapovani netfilteru na Win paket filtr? Jezisimarja, jadro exportuje jakesi rozhrani, jake userspace nastroje k jeho ovladani uzivam, je ciste ma vec.
Proc se mam ucit novy nastroj, jestlize mi ten stary vyhovuje, jsem s jeho prednostmi i zapory seznamen a jeho uzivanim nikoho neposkozuju? Kdybych se ucil pokazde nove genialni nastroje, ktere prichazeji (a zase odchazeji), jaksi by mi nezbyval moc volny cas. Ucim se tehdy, ma-li to pro mne vyznam (ci me to v danou chvili bavi). Ne proto, ze to za mne nekdo jiny rozhodnul.
iptables, buď ho budete muset změnit natolik, že tomu původnímu nebude vůbec podobný, nebo to bude fungovat jen ve velmi omezené míře a každou chvíli vás nepříjemně překvapí naprosto neočekávaným chováním. Což je v podstatě přesně totéž, jako v případě příkazu ifconfig, jen to tady bude ještě výraznější.
Ale to je vas pocit, ne muj. Ja vim, co ifconfig provadi a jak to dela a mi to vyhovuje.
Není to můj pocit. Je mi líto, ale už mnohokrát jste v této diskusi dal najevo, že to nevíte. K vlastní velké škodě.
) a nestydím se označit ho za demagogický blábol
... ip a nesmyslné preferování programu ifconfig, ačkoli je označen za "zbytečný" snad někdy od roku 1992 (to datum berte s rezervou, ale bude to tak nějak)hmmm ...
man ip
HISTORY
ip was written by Alexey N. Kuznetsov and added in Linux 2.2.
hmmm ... linux history
Version 2.2 was released on Jan 26th 1999... nevím, kdy byl
ifconfig poprvé označen za "zbytečný" (kým? Torvaldsem?), výše uvedená věta může být formálně správně, nicméně v souvislosti s jeho nahrazením ip je to totální pitomost
další perla následuje:
Přitom program ip má tak přirozenou syntaxi! ... Přijde ještě někomu teď syntax programu ip nelogická? ... Tím jsme snad rozbili argumenty škarohlídů, kteří tvrdí, že ip ma nelogickou syntax ...hm, subjektivní výkřiky o tom, jak je něco krásně logické, nejsou platnou argumentací pro to, že to opravdu logické je; rovněž výtah z dokumentace je v tomto případě pořád jenom výtah z dokumentace a nikoliv důkaz nějaké logiky ... autor asi chtěl říct místo "logické" spíše "jednoduché" ... hm, tak nevím, ale jestliže v typickém případě mají příkazy
ip a add 192.168.0.1/24 brd + dev eth1
ifconfig eth1 192.168.0.1
stejný efekt, pak mi na tom nepřipadá ani nic jednoduššího ... a pokud mám mluvit o nějaké "logičnosti", pak mě tedy přijde (IMHO) logičtější říci prvně s čím chci manipulovat (ethX) a teprve potom co s tím chci dělat (objektem je pro mě rozhraní, adresa je jen jeho parametrem)
Kazdopadne jsi asi vubec nepochopil, proc jsem to napsal.
Dodam jen, ze jsem pevne presvedcen, ze obcas ucel sveti prostredky.
Kazdopadne se tu snazim neceho docilit a mrzi me, ze do toho furt nekdo rejpe. Ten blog byl cileny predevsim na novacky, aby se vy* na ifconfig a zacali na novych jadrech pouzivat nastroj, ktery se pouzivat ma. Nemel vyvolat zadne flamy.
Co se nesmyslneho propagovani ifconfigu tyce, myslim, ze ta veta nema s demagogii nic spolecneho. Je to proste tak. Lide, kteri zacali kdysi "davno" na starych jadrech se ho naucili pouzivat a stalo se pro nektere z nich alfou i omegou. A cpou to kazdemu furt dokola ackoli doba se uz zmenila. To jsem mel na mysli.
Za zbytecny byl oznacem uz samotnou zmenou koncepce v jadre. Ze to nekteri jedinci nezaregistrovali je jina, velice smutna, vec. Snazim se tuto jejich chybu napravovat kde se da (a ano, priznavam, ze to datum bylo premrstene, ale kdyz Ti to tak vadi, tak jsem to opravil, kazdopadne to s tim datumem mozna melo vetsi prsychologicky efekt nez to ma ted).
Jestli je pro tebe prirozenejsi konstruovat prikazy tak, ze si je musis pamatovat, nez tak, ze si jednou prectes obecny princip a dal uz jen k systemu "promlouvas", je tvoje vec. Pro me je prirozenejsi mluvit nez si u kazdeho prikazu pamatovat tuny parametru a podobne. Nepresvedcis me, ze syntax ip neni jazykove logictejsi nez syntax programu ifconfig. Proste se Ti to nepovede. Souhlasim jen, ze jazyk, o ano, muze byt velice subjektivni (stale ale jeste existuji ustalene vseobecne pojmy, ktere jsou ve spolecnosti vnimany urcitym zpusobem), ale nikoli princip.
Omezeni logiky jen na jakysi formalizovany vyznam se mi nelibi. Co treba logika v hudbe? Co treba logika v umeni? Nemaji snad Picasovi obrazy take svoji (vlastni) logiku? Ja nevystudoval technickou skolu a proto asi pohlizim na pojem "logika" v mnohem sirsim kontextu. Samosebou jsem take prosel vysokoskolskymi kurzy formalni logiky, ale stale jeste vim, ze slovo "logika" ma i normalni lidsky vyznam. Pro vetsinu lidi "logicke" neznamena logicke ve smyslu nejakych implikaci. Vetsina lidi ani netusi co napriklad takovy pojem implikace znamena.
Priliz presne uvazovani muze byt casto spise na skodu. Napriklad tvuj dodatek "obrazne", kdyz mluvis o "zvednuti ze zidle". Snad si proboha nemyslis, ze by si nekdo myslel, ze jsi opravdu vstal ze zidle. Ten obrat je uz dobre ustaleny a nikdo, opakuji nikdo, by si snad nemyslel, ze kdyz reknu, ze me neco, nejaka zprava nebo cokoli "zvedlo ze zidle", ze jsem zacal pobihat po pokoji. Prirozene z toho obratu citime, ze to clovek rika proto, ze se citil na to, aby se zvedl ze zidle a zacal rozrusene pobihat okolo. Ale vsichni vime, ze to dotycny neudelal a ze se jen snazi neco podtrhnout (sem bys asi take napsal slovo "obrazne"). A proc to tak rozpitvavam? Protoze si myslim, ze jsi ten blogpost nepochopil presne proto, ze jsi ztratil pojem "logiky" v sirsim, obecnejsim uzu.
BTW: Jsem nepritelem formalismu jakoz i vsech ostatnich "-ismu". Ovsem tuto vetu prosim radeji nekomentuj, nehodlam zde vysvetlovat svuj celkovy svetonazor.
ifconfig už poměrně dlouho v Linuxu podporování není.
ifconfig je user space program s jistou koncepcí, který slouží jako konfigurační rozhraní k driverům jádra, které už poměrně dlouho pracují s koncepcí naprosto odlišnou. A taková kombinace prostě nemůže dělat dobrotu, stejně jako by nedělalo dobrotu, kdybyste se snažil používat iproute2 na starých jádrech. Stejně jako kdybyste používal ipchains nebo ipfwadm na jádrech řady 2.4 nebo 2.6.
ifconfig je tu proste natolik zavedeny a na zakladni ukony natolik vyhovujici, ze pro valnou vetsinu lidi je dostacujici. A mi, at se vam to libi nebo ne, vyhovujici a pro mne fungujici
Funguje tak, jak deklaruje, nic vice, nic mene. Funguje jinak, nez vy by jste si pral. Ale to neznamena, ze jej mate vnucovat vsem. Kdyby jste prestal uzivat hlasky jako "nefunguje" apod. a spise se zameril na tu pozitivni argumentacni stranku veci, uz davno bych vam tady neodporoval
Argumentace s ipchains je o zcela necem jinem. ifconfig je ciste userspace vec, coz sam rikate. Pro podporu rozhrani ipchains (a ipfwadm) muselo byt iptables doplneno o specialni moduly (a prekvapive dost lidi s tim dal nadsene zilo).
…a na zakladni ukony natolik vyhovujici, ze pro valnou vetsinu lidi je dostacujici. A mi, at se vam to libi nebo ne, vyhovujici a pro mne fungujiciFunguje tak, jak deklaruje, nic vice, nic mene. Funguje jinak, nez vy by jste si pral. Ale to neznamena, ze jej mate vnucovat vsem. Kdyby jste prestal uzivat hlasky jako "nefunguje" apod. a spise se zameril na tu pozitivni argumentacni stranku veci, uz davno bych vam tady neodporoval
Nepřestanu tvrdit, že nefunguje, protože je to pravda. Nebo si snad myslíte, že lze označit slovem funguje nástroj, který po příkazu 'ifconfig eth0:0 mtu 9000' nastaví hodnotu MTU na 9000 rozhraní eth0, aniž by vypsal jediné varování? Problém není v tom, že by ifconfig fungoval jinak, než si přeji; problém je v tom, že funguje jinak než jádro. A to je u konfiguračního rozhraní k jádru problém naprosto zásadní.
Argumentace s ipchains je o zcela necem jinem. ifconfig je ciste userspace vec, coz sam rikate. Pro podporu rozhrani ipchains (a ipfwadm) muselo byt iptables doplneno o specialni moduly (a prekvapive dost lidi s tim dal nadsene zilo).
Nikoli, princip je naprosto stejný. V jádrech 2.2 byl jakýsi paketový filtr a k němu user space konfigurační nástroj jménem ipchains (ke zmatení dochází tím, že se používal název ipchains i pro tu jadernou část). V jádrech 2.4 se objevil zcela odlišný paketový filtr jménem netfilter a k němu user space konfigurační nástroj jménem iptables. Kvůli snazšímu přechodu je dočasně v jádře vrstva, která umožňuje emulovat rozhraní používaná původním příkazem ipchains. A přesně stejný vztah jako mezi ipchains a iptables je i mezi ifconfig a ip. Rozdíl je jen v tom, že přestože je ipchains obsolete kratší dobu než ifconfig, téměř nikdo ho už naštěstí nepoužívá.
Ja tam ale proste ten rozdil vidim, protoze v pripade paket filtru doslo k zasadni zmene rozhrani jadra. V pripade sitovych rozhrani doslo k jiste zmene filozofie. Ale stale se s tim da funkcne zit dostatecne bez problemu, jsem-li si tech rozdilu vedom. Ja vase jadro nezatezuju existenci ifconfigu.
stale dokola omilate pouze jednu vec - praci s virtualnim rozhranim ethX:0. To opravdu povazujete za tak zasadni nezmenitelnou vec?
Nezměnitelné to evidentně není, když se to od základu změnilo. Zmiňuji to hlavně proto, že je to jedna z věcí, kde je rozdíl (a následné problémy) dobře vidět a je to dostatečně elementární. Kdybych měl vyjmenovávat, co všechno ifconfig, route, arp a další neumějí nebo umějí velmi omezeně (a leckdy i špatně), bylo by toho na seriál… Jenže vy byste stejně řekl, že to nepotřebujete. Tak vám to raději demonstruji na příkladu, se kterým se může setkat skoro každý a který nevyžaduje žádné hlubší znalosti.
Ja tam ale proste ten rozdil vidim, protoze v pripade paket filtru doslo k zasadni zmene rozhrani jadra. V pripade sitovych rozhrani doslo k jiste zmene filozofie.
Ne, to je právě to, co je úplně stejné. V obou případech došlo k naprosto zásadnímu přepracování celého subsystému.
uprimne ... sekundarne ip ci virtualne interface) povazujem za experimentalne featuresky. koncovy stroj (desktop/server) ma mat jednu mac, jednu ip. zvysok riesi router/gateway.
sekundarne ip ci virtualne interface) povazujem za experimentalne featuresky. koncovy stroj (desktop/server) ma mat jednu mac, jednu ip. zvysok riesi router/gateway.
Zajímavý názor. Abych v tom měl jasno: takže i virtuální servery např. u Apache považujete za experimentální featuresku, která nemá na serveru co dělat? Ne, ne vždy to lze vyřešit jménem - např. pro HTTPS.
ifconfig.
ipchains a ipfwadm, přestože jsou do jisté míry emulována rozhraní, která tyto příkazy používají - ale právě jen do jisté míry. Mimochodem, zahlédl jsem zmínku o tom, že emulace rozhraní pro ipchains by měla být v dohledné době odstraněna - a to je ipchains obsolete o jednu stabilní řadu později než ifconfig.
Nematte lidi. I v nejnovejsich jadrech funguje naprosto spolehlive s tim, co nabizi. Ano, ip prinasi mnohe veci, ale neprinasi nic tak zasadniho, aby si mnozi uzivatele nevystacili s klasickym proverenym ifconfig/route.
ifconfig/route funguje naprosto spolehlivě pouze na počítači, kde víte, že nikdo iproute2 nepoužil. Jakmile se někde používají pro routování nějaká pravidla, příkaz route vám IMHO ukáže jen defaultní routovací tabulku. A přitom se může routovat podle úplně jiných tabulek. Takže spokojený uživatel ifconfig/route pak bude bádat nad tím, proč se počítač zbláznil a routuje úplně jinak, než podle tabulky má. A on se nezbláznil. To si jen uživatel vystačil s klasickým prověřeným ifconfig/route
Pro vasi predstavu, balicek net-tools (obsahujici ifconfig) v Debianu patri mezi "Dulezite", kdezto iproute (obsahujici ip) patri mezi "Volitelne". Ne, ze by to neco klicoveho prokazovalo,...Prokazuje to jediné - že se nikdo ještě nedostal k tomu, aby přepsat třeba takový ifupdown, který na net-tools závisí a na kterém závisí všechno ostatní. Když koukám do zdrojáků, tak na první pohled by to nemuselo být tak těžké předělat.
screen, protoze v praci skoro nikde nebyl a ja jsem bez nej jak bez ruky...
) Takze nechme kazdému at si rozhodne co bude ci nebude pouzívat.
Ale není jediný důvod proč by měly distribuce v základu obsahovat překonaný zastaralý nástroj, když mohou rovnou zahrnout nový plně použitelný.Treba proto, ze tvurci distribucí resp. jejich uzivatelé si to nemyslí. Pokud by tomu tak bylo pak by tak jiz jiste ucinili.
Z toho pak plynou nesmyslné úvahy stačí mi ifconfigJasne vsichni jsou normální jen já jsem letadlo. Me stací. Nemyslím, ze my to tady vyresíme. Pokud nejste spokojen se soucasným stavem tak vám preci nic nebrání obrátit se na vývojáre vasí distribuce at to zmení.
Když tedy někomu stačí ifconfig, může si ho stáhnout a nainstalovat sám.Souhlasím klidne bych to udelal.
Z toho pak plynou nesmyslné úvahy jako stačí mi ifconfig.Jakým právem povazujes úvahy tech, kterí ifconfig jeste pouzívají za nesmyslné? Jsi snad ten kdo má právo ríci co je dobré pro me, MUSÍ být dobré i pro ostatní? Myslím, ze ne. To si musí kazdý rozhodnout sám. Kazdý by mel vedet sám co je pro nej dobré a co ne. Ano muzeme tady shrnout nevýhody pouzívání ifconfig a poradit ostatním co by meli pouzívat, ale to je tak vse.
Ale není jediný důvod proč by měly distribuce v základu obsahovat překonaný zastaralý nástroj, když mohou rovnou zahrnout nový plně použitelný.No nejaký zrejme bude, kdyz tam je stále.
Mě zase zaráží tyhle věčné závěry ,,ať si používá každý co chce``.Ale vzdyt je to proboha pravda. Pochopil bych to pokud by pouzívání ifconfigu melo za následek nejaké globální problémy. Ale tím, ze ho pouzívám mohu zpusobit problémy pouze sobe a lidem v síti, kterou spravuji (v tom prípade, bych ho nepouzíval ze?). Sít nikoho jiného tím netrpí. Jedním z duvodu pro které pouzívám linux je práve to, ze si pouzívám to co chci já, co me vyhovuje. A pokud ne tak pouziji neco jiného. Já vám preci nikomu neberu, ze ip je pro správu vasí síte lepsí, já jen ríkám, ze do toho co pouzívám já je kazdýmu prd.
ifconfig je špatný příklad (i když také patřím k těm, co ho stále ještě používají), ale mohu uvést třeba nslookup nebo route.
nslookup už je nějakou dobu deprecated. Ovšem kdo ho opustí (zvykne si používat host nebo dig), a pak je zkonfrontován se systémem, který obsahuje jen nslookup (starší distribuce Linuxu, ale třeba i WinXP), bude tápat. Podobně i route. Nebo naopak, někdo z jiného systému přijde k Linuxu, a bude jen zírat jako puk (pokud by třeba nslookup zmizel).
Já vím, je to problém. Na jedné straně máme nové a dobře použitelné nástroje (které ovšem nejsou zdaleka všude), a na straně druhé pak široce rozšířené nástroje (které mají špatnou syntaxi, omezený rozsah funkcí apod.).
Takže ano, používejme lepší nástroje, ale ty špatné budeme muset asi ještě nějakou dobu strpět. Podobně, jako ve standardní knihovně přetrvává nebezpečná funkce gets().
ifconfig, myslím samozřejmě celou tu sadu nástrojů včetně route nebo arp.
Podobně, jako ve standardní knihovně přetrvává nebezpečná funkce gets().
Kdyby přetrvávala jen ve standardní knihovně, dalo by se to přežít (jako kdyby ifconfig přetrvával jen v adresáři /sbin). Jenže ona bohužel přetrvává v celé řadě používaných programů a dokonce i knihoven. A nejen ona, takových příkladů je víc: tempnam(), localtime(), strerror(), …
gets(), protože když je někdo použije nevhodně (zrovna gets() se snad ani bezpečně použít nedá), dá se očekávat, že si toho někdo všimne, napíše exploit a začne se to řešit.
Oproti tomu nereentrantní funkce nebo obecně thread unsafe konstrukce jsou nepříjemné tím, že dlouho nevadí, dokud se příslušný kus kódu nezačne používat v multithreadové aplikaci (nebo asynchronně fungující aplikaci). Pak z toho je těžká hlava a často je lepší napsat to celé znovu od začátku, než hledat problematická místa. Viz např. stále značně neuspokojivý stav (a nepříliš optimistické vyhlídky) ohledně kombinace Apache 2 worker s PHP.
Viz např. stále značně neuspokojivý stav (a nepříliš optimistické vyhlídky) ohledně kombinace Apache 2 worker s PHP.Nedělám si iluze, že bude MPM worker rozumně použitelný s PHP. Tím spíš, že Apache 2.2 má MPM event, který nenechává viset vlákna na otevřených persistentních spojích a je celkově efektivnější. Proto se funkčnost PHP bude zřejmě řešit už jen pro tento model (který je ovšem zatím označen jako experimentální), a nikoli už pro worker. Ale to jsou jen moje spekulace, do hlav vývojářů nevidím (a ani jsem se jich neptal), ani jsem v tomto smysl nic jednoznačného nečetl.
Co ti hodlám vzít je ifconfig ,,dostupný všude``.Já se nedám
Ne to byl samozrejme vtip. Me osobne nedelá problém prejít na ip.
Tedy chci abys říkal - já používám zastaralý nástroj ifconfig, který jsem si musel doinstalovat, protože v distru nebyl, neumí nastavit půlku možností co jádro zvládá, ale používám .Ano ríkám, pouzívám zastaralý nástroj ifconfig a jsem si vedom vech dusledku..... atd. Neumí sice nastavit pulku mozností co jádro zvládá, ale ME OSOBNE to vubec nevadí. Rekl bych totiz, ze tady pláces na spatném hrobe ( a samozrejme nejen ty). Zkusil jsi kontaktovat vývojáre FC (pokud jsem dobre koukal tak je to tvoje distro, stejne tak jako moje) a pokud ano jak se k tomu staví oni?
apt-cache search ipbalik jmenem "ip" nevidim, co delam spatne, cemu nerozumim?
ip rule', 'ip maddress', 'ip mroute' a 'ip tunnel'. Ale nejsem si teď jistý, jestli vůbec nějaké existují, tj. jestli příslušná funkcionalita existovala už před jádrem 2.2.