NetworkManager 0.9.10

Vyšel NetworkManager 0.9.10, sada nástrojů pro správu síťových připojení. Novinky jsou popsány v příspěvku We’ll Build A Dream House Of Net na blogu Dana Williamse. Zmínit lze například nmtui, nový TUI nástroj postavený nad knihovnou ncurses, jenž překlenuje mezeru mezi CLI nástrojem nmcli a GUI utilitami vyžadujícími X Window System, Wayland nebo Mir.

7.7.2014 07:43 | Ladislav Hagara | Nová verze

Komentáře

[mankind_boost]

Konecne tui nastroj, haleluja!

[vain]

Ten CLI byl docela dobrý, ale je fakt, že TUI vždy potěší

[miros]

Vypada to pekne. Jen je divny ze pisou curses-based, kdyz to podle zdrojaku pouziva newt (ktery jede nad slangem a ne curses).

[ukarr]

Network Manager? Já žiju spokojeně s "ExecStart=/usr/sbin/ip link set dev eth0 up" v systemd sit.service

[Peter Golis]

Mne stačí aj netctl-ifplugd@eth0.

[ukarr]

Taky mi stačily skripty - než komunisti nacpali do Fedory systemd. To mělo za následek, že služby nastartovaly dříve než byla funkční síť a půlka jich proto zdechla a druhá půlka sice běžela, ale nefungovala.

[pavlix]

Odkaz na bug report(y) by nebyl? Mám vyzkoušeno, že to vše lze se systemd velmi dobře řešit. Maintaineři se z pochopitelných důvodu nechtějí systemd učit, takže je občas potřeba jim to řešení do bug reportu přímo napsat. Nadávání v diskuzi je jistě bohulibý způsob ventilování rozhořčenosti, ale linky na bugreporty skutečně i někomu pomůžou ;).

[ukarr]

Proč psát bugreporty, když komunistické vedení má vlastní linii a záměrně nepodporuje statické připojení sítě (lze dohledat na netu)? Ostatně můj příspěvek nebyl nadávání, jen jsem upozornil, že se připojení často dá řešit jednoduchým .service souborem a tím pádem není zapotřebí NetworkManager, tedy ani jeho nastavovátka. Pokud by někdo měl zájem o ten network-static.service soubor a nechtěl by hledat podobný někde na netu, mohu ho zde zveřejnit.

[pavlix]

Myslel jsem si hned, že jsi jen troll, ale snažím se dát šanci každému. Statickou konfiguraci sítě podporují /etc/init.d/network, NetworkManager i systemd-networkd.

[ukarr]

Jasně, jsem troll, kterého baví psát vlastní services do systemd.

Co se týče té podpory statické konfigurace "/etc/init.d/network, NetworkManager i systemd-networkd" - to první nefunguje (startuje služby dřív než je k disposici síť), to druhé je kanón na vrabce a to třetí neznám ( No such file or directory ).

[pavlix]

Bez odkazu na bug report nebo zdroj na podobné úrovni si dovolím toto skutečně považovat za pouhý trolling.

[ukarr]

sám seš bugreport

[Petr Ježek]

Kdo sám nic neumí, o to více to podsouvá jiným. Dnes je kdejaký mazánek odborníkem na komunismus. Překonat odpor k čemukoli nad úrovní triviality je pro některé ukárrky neřešitelný úkol... Pavlix ukázal cestu, cesta odmítnuta a ukazatel cesty pro výstrahu rozmlácen. I takoví jsou zdejší přispěvatelé...

[pavlix]

Lépe bych to nenapsal.

[TM]

Měl jsem podobný problém se systemd pod OpenSuse - při shutdownu jsem potřeboval spustit script, který potřeboval něco udělat na vzdáleném stroji. Bohužel systemd na dokončení scriptu nepočkalo, shodilo síť dříve a script tedy nemohl úspěšně dokončit svoji práci...
S network-managerem to nesouviselo, protože ten používám jen na laptopech, píšu to jako zajímavost. Než bych se složitě dohadoval s podivnými lidmi kolem systemd, raději jsem to vyřešil jinak - ano, prasácky, leč funkčně. Dříve jednoduchý úkol, teď jebárna...
Ti lidé - jejich chování - prostě člověka odrazují od toho, aby s nimi cokoliv řešil.

Oceňuji váš hrdinný boj proti trollům bez kladného vztahu k převratnému vynálezu - systemd. Vy se snažíte a ti hajzlové nevděční mají pořád rádi UNIX. To jednoho na.ere...

[pavlix]

Měl jsem podobný problém se systemd pod OpenSuse - při shutdownu jsem potřeboval spustit script, který potřeboval něco udělat na vzdáleném stroji. Bohužel systemd na dokončení scriptu nepočkalo, shodilo síť dříve a script tedy nemohl úspěšně dokončit svoji práci...

Předpokládám, že odkaz na bug report s přesným popisem problému asi nebude, a stejně tak nebude informace, zda se chybá týká i aktuálních verzí. Já jsem si s tím začal hrát relativně nedávno, ale jak závislosti, tak pořadí spouštění a ukončování mi podle všeho fungují perfektně, navíc ten jazyk závislostí umí věci, o kterých si může OpenRC nechat zdát.

Ti lidé - jejich chování - prostě člověka odrazují od toho, aby s nimi cokoliv řešil.

Souhlasím a nemám pro tenhle problém žádné rozumné řešení.

Oceňuji váš hrdinný boj proti trollům bez kladného vztahu k převratnému vynálezu - systemd. Vy se snažíte a ti hajzlové nevděční mají pořád rádi UNIX. To jednoho na.ere...

Člověk se snaží diskutovat střízlivě a fakticky, a hned se na něj sesypou obě dvě skupiny fanatiků, kteří mají fakta zcela u prdele a jen každý bečí ohranou písničku svých bratří.

[TM]

Pořadí bylo správné - shození sítě se skutečně spustí po mém scriptu. Nicméně s ním pak běží paralelně a nevím, jak to donutit, aby počkalo, až bude hotový. Připouštím, že mně něco mohlo uniknout, ale pracovat se systemd se učím řekl bych dost pilně - bohužel mně nic jiného nezbývá. Jinak mám ten vynález rád jak osinu v pr....
Snad se nedožiju toho, že jednou na mě po bootu CentOS 9 vybafne nádherný prompt ve tvaru C:\> s Poeteringovým modt, jak je to cool a superultramega úplně nejlepčejší.

[ukarr]

"Dnes je kdejaký mazánek odborníkem na komunismus." WTF?

[Bubak]

Hm, priznam se, ze nez zkoumat, co je potreba pro nejake network managery a cert vi jake ...ery, radsi pouziju trivialni skript. Ty dva radky (spusteni wpa_supplicanta a dhcpcd) mi opravdu nepripadaji slozitejsi nez konfigurovat cokoliv divokeho... Jo, jasne, obcas zapsat ctyri pet radku do konfiguraku wpa_supplicanta, ale i to mi prijde tak jednoduche, ze nemam jakoukoliv potrebu jinych nastroju nez vi

Ne, ze bych to chtel jinym vnucovat, ale ackoliv ukarr, bo jak si rika, bude tak trochu troll, rozhodne nema uplne nepravdu.

[pavlix]

Hm, priznam se, ze nez zkoumat, co je potreba pro nejake network managery a cert vi jake ...ery, radsi pouziju trivialni skript.

To my všichni, pokud je to pro nás v danou chvíli výhodnější, ale to jaksi není předmětem diskuze.

[ukarr]

Přesně to, Pavlixi, JE předmětem diskuse. Že raději použiji jednoduchý skript (nebo v mém případě jednoduchou .service, protože nemám na vybranou kvůli systemd) než komplexní NetworkManager. Rozčílil ses zbytečně, protože na NM sám děláš a máš k němu citový vztah. Nijak jsem NM přece nehodnotil, možná je to slušná věc (zvlášť se mi líbí možnost mít jen potřebné moduly), ale značná část lidí ho prostě nepotřebuje. Přesto ale NM narvou do distribuce a tak ho tam zaháčkují, že ho člověk musí používat chtě-nechtě. To je prostě opruz a NM to schytá od právem na****ých uživatelů, i když za to sám asi nemůže. Prostě - švýcarský nůž je jistě krásný, občas se může hodit, ale když se jdu porvat do hospody, tak si beru klasický nůž. ... ono i ukrojit chleba je s viktorinoxem trochu pruda ... ne, že by to nešlo ... jo, takhle, v dnešních distribucích je už chléb krájený ..

[kavol]

heh, a já jsem myslel, že většina lidí nosí do hospody baseballky nebo mačety ...

a takovej Victorinox Nomad je na chleba vcelku v pohodě, problém je, že distributoři se rozhodli, že ani na něj nemáš nárok, a kdyby sis ho náhodou chtěl v distru udržovat sám, jistě můžeš, jsme přece děsně otevřený, tak nekecej a přilož ruku k dílu, když máš problém, tak si ho můžeš vyřešit, nikdo jinej to za tebe neudělá, tak si nestěžuj a makej, a bláblá, ale reálně pak dělaj všechno proto, aby se MiniChamp nedal odinstalovat a i při běhu konfliktil s Nomadem a píšou Featury (nebo "Change") na odstranění duplicit, když už tam stejně mají ten MiniChamp ... sice nakonec uznají, že sem tam někdo fakt potřebuje, aby chleba nebyl krájený, ale naoplátku prohlásí za standard pro chleba, že může mít výšku maximálně 3 cm, a přes to vlak nejede a všechny pekárny se musí přizpůsobit

[pavlix]

Přesně to, Pavlixi, JE předmětem diskuse.

Pokud vím, je předmětem diskuze tvoje stížnost na údajnou chybu v systemd, ke které není k dispozici bug report a tudíž se můžeme jenom dohadovat, o jaký typ chyby se jedná, co všechno tou chybou trpí a zda není jen produktem neznalosti či neschopnosti administrátora.

Rozčílil ses zbytečně

Spíše si zbytečně promítáš své vlastní pocity do svých představ o druhých.

Povzdechnul jsem si nad tím, že jsem potkal dalšího z mnoha lidí, kteří dávají přednost nadávání před přiložením ruky k dílu. Na to má samozřejmě každý právo, ale já osobně vyhledávám trochu jiný typ lidí.

Přesto ale NM narvou do distribuce a tak ho tam zaháčkují, že ho člověk musí používat chtě-nechtě.

Předpokládám, že žádné odkazy na bug reporty pro dané distribuce ohledně jejich používání bez NetworkManageru neboudou, že? Takže se opět nedozvím ani přesný popis chyby, ani názor maintainerů, ani jestli sis celé to tvrzení nevycucal z prstu.

[ukarr]

"Pokud vím, je předmětem diskuze tvoje stížnost na údajnou chybu v systemd"

Přečti si můj první příspěvek v téhle diskusi a uvidíš, že jsem si na žádnou chybu v systemd nestěžoval.

Později jsem jen zmínil fakt, že použití init.d skriptů pro startování sítě je většinou nepoužitelné, protože služby využívající síť startuje systemd dříve než staré soubory v init.d, tedy síť naskočí pozdě a služby nemohou navázat port. To není žádný bug do bugreportu, to je známý fakt a dle vyjádření lidí z RH je použití network service z init.d nadále nedoporučované. Co to má mít společného se schopnostmi administrátora netuším.

"lidí, kteří dávají přednost nadávání před přiložením ruky k dílu"

Jak poznáš z věty "Já používám vlastní sit.service", že dávám přednost nadávání? Linux používám dvacet let a do různých projektů jsem se napříspíval až dost. I do kernelu.

Posledním dvěma větám nerozumím. Já přece o žádné chybě nemluvil. Žádná chyba = žádný bugreport.

[pavlix]

Start služeb ve špatném pořadí osobně za chybu (v některém balíku) považuju, zvláště v situaci, kdy systemd podporuje závislosti na klíčových službách podporuje i v initskriptech.

[lnykryn]

U mě je řazení služeb v pořádku $ systemctl show network.target --property After After=NetworkManager.service network.service NetworkManager-wait-online.service wpa_supplicant.service

Ale network initscript je rozhodně deprecated. Značná část by zasloužila přepsat (např. celá podpora IPv6) a zbytek je takový křehký, jen v poslední době se tam museli přidávat dva konfigurovatelný sleepy. A není nikdo komu by se to dál chtělo udržovat.

Takže aktuálně je v plánu doplnit do networkd featury co umí network, napsat generátor na čtení ifcfg konfigurace a initscript by mohl zmizet do f23.

[Bedňa]

Přesto ale NM narvou do distribuce a tak ho tam zaháčkují, že ho člověk musí používat chtě-nechtě.

Zrovna NM je niečo čo vyhodíš zo systému za dve sekundy. Dokonca aj ten Gnome NM nieje na ničom inom závislý. Toto si trafil vedľa.

[pavlix]

Tož ale zbytek systému bez toho určitě nebude fungovat a nejspíš se to ani samo nepřipojí k síti ;).

[Bedňa]

Ale však stále tam mám, "ip" a dhcpclienta.

Citujem ho:

Že raději použiji jednoduchý skript

[pavlix]

Ten smajlík tam měl svůj účel :).

[Bedňa]

A jasne .)

Inak včera ako som kompolival NM som sa presne do tejto situácie dostal, najskôr som odinštaloval starý NM a teraz ideme stiahnuť balíčky na kompiláciu :)

Zrovna autokonfigurácia sietí a autopripájanie diskov beriem ako oblasť kde mi automatizácia zjednošuje život. Tak neviem čo všetci pindajú.

[ukarr]

"Zrovna NM je niečo čo vyhodíš zo systému za dve sekundy"

Proč mne furt někdo o něčem poučuje? NetworkManager jsem samozřejmě vyhodil za dvě sekundy, ale třeba NetworkManager-glib už vyhodit nemůžu, protože mi při tom zmizí půlka aplikací včetně GIMPu (WTF?).

[Bedňa]

To je bug balíčkovača vo Fedore o tom som nevedel, tak máš čiastočne pravdu. Ja sa pohybujem medzi Ubu, Debianom a Gentoo, tam som na toto nenatrafil.

[pavlix]

NetworkManager-glib už vyhodit nemůžu, protože mi při tom zmizí půlka aplikací včetně GIMPu (WTF?).

Vždyť je to jen knihovna, i kdyby zbytečná, to je v binárních distribucích vcelku běžné.

[ukarr]

ano, ano. Jako ve Widlích.

[2X4B-523P]

naopak, ve widlích máš jednu knihovnu klidně stokrát...

[kavol]

[root@kvolny bin]# yum remove NetworkManager*
Zavedené moduly: auto-update-debuginfo, fastestmirror, langpacks, merge-conf, ps, refresh-packagekit
Řešení závislostí...
--> Kontrola transakce spuštěna
---> Balíček NetworkManager.x86_64 1:0.9.9.0-41.git20131003.fc20 bude smazán
--> Zpracování závislostí: NetworkManager >= 0.9.9.0 pro balíček: 2:libnm-qt-0.9.8.2-1.201404225cff3c5.fc20.x86_64
--> Zpracování závislostí: NetworkManager >= 1:0.7.1-3.git20090414 pro balíček: anaconda-20.25.16-1.fc20.x86_64
--> Zpracování závislostí: NetworkManager >= 0.9.8 pro balíček: kde-plasma-nm-0.9.3.4-4.20140520git043bbae.fc20.x86_64
---> Balíček NetworkManager-glib.x86_64 1:0.9.9.0-41.git20131003.fc20 bude smazán
--> Zpracování závislostí: NetworkManager-glib >= 1:0.9.9.0-26 pro balíček: nm-connection-editor-0.9.9.0-10.git20140123.fc20.x86_64
--> Zpracování závislostí: libnm-glib-vpn.so.1()(64bit) pro balíček: libnm-gtk-0.9.9.0-10.git20140123.fc20.x86_64
--> Zpracování závislostí: libnm-glib-vpn.so.1()(64bit) pro balíček: nm-connection-editor-0.9.9.0-10.git20140123.fc20.x86_64
--> Zpracování závislostí: libnm-glib.so.4()(64bit) pro balíček: geoclue-0.12.99-5.fc20.x86_64
--> Zpracování závislostí: libnm-glib.so.4()(64bit) pro balíček: libnm-gtk-0.9.9.0-10.git20140123.fc20.x86_64
--> Zpracování závislostí: libnm-glib.so.4()(64bit) pro balíček: nm-connection-editor-0.9.9.0-10.git20140123.fc20.x86_64
--> Zpracování závislostí: libnm-util.so.2()(64bit) pro balíček: geoclue-0.12.99-5.fc20.x86_64
--> Zpracování závislostí: libnm-util.so.2()(64bit) pro balíček: libnm-gtk-0.9.9.0-10.git20140123.fc20.x86_64
--> Zpracování závislostí: libnm-util.so.2()(64bit) pro balíček: nm-connection-editor-0.9.9.0-10.git20140123.fc20.x86_64
---> Balíček NetworkManager-l2tp.x86_64 0:0.9.8.6-1.fc20 bude smazán
--> Zpracování závislostí: NetworkManager-l2tp pro balíček: kde-plasma-nm-l2tp-0.9.3.4-4.20140520git043bbae.fc20.x86_64
---> Balíček NetworkManager-openconnect.x86_64 0:0.9.8.0-2.fc20 bude smazán
--> Zpracování závislostí: NetworkManager-openconnect pro balíček: kde-plasma-nm-openconnect-0.9.3.4-4.20140520git043bbae.fc20.x86_64
---> Balíček NetworkManager-openswan.x86_64 0:0.9.8.4-2.fc20 bude smazán
--> Zpracování závislostí: NetworkManager-openswan pro balíček: kde-plasma-nm-openswan-0.9.3.4-4.20140520git043bbae.fc20.x86_64
---> Balíček NetworkManager-openvpn.x86_64 1:0.9.9.0-0.1.git20140128.fc20 bude smazán
--> Zpracování závislostí: NetworkManager-openvpn pro balíček: kde-plasma-nm-openvpn-0.9.3.4-4.20140520git043bbae.fc20.x86_64
---> Balíček NetworkManager-pptp.x86_64 1:0.9.8.2-3.fc20 bude smazán
--> Zpracování závislostí: NetworkManager-pptp pro balíček: kde-plasma-nm-pptp-0.9.3.4-4.20140520git043bbae.fc20.x86_64
---> Balíček NetworkManager-vpnc.x86_64 1:0.9.8.2-2.fc20 bude smazán
--> Zpracování závislostí: NetworkManager-vpnc pro balíček: kde-plasma-nm-vpnc-0.9.3.4-4.20140520git043bbae.fc20.x86_64
--> Kontrola transakce spuštěna
---> Balíček anaconda.x86_64 0:20.25.16-1.fc20 bude smazán
--> Zpracování závislostí: anaconda >= 20.11 pro balíček: initial-setup-0.3.10.1-1.fc20.noarch
---> Balíček geoclue.x86_64 0:0.12.99-5.fc20 bude smazán
--> Zpracování závislostí: libgeoclue.so.0()(64bit) pro balíček: webkitgtk3-2.2.7-1.fc20.x86_64
---> Balíček kde-plasma-nm.x86_64 0:0.9.3.4-4.20140520git043bbae.fc20 bude smazán
---> Balíček kde-plasma-nm-l2tp.x86_64 0:0.9.3.4-4.20140520git043bbae.fc20 bude smazán
---> Balíček kde-plasma-nm-openconnect.x86_64 0:0.9.3.4-4.20140520git043bbae.fc20 bude smazán
---> Balíček kde-plasma-nm-openswan.x86_64 0:0.9.3.4-4.20140520git043bbae.fc20 bude smazán
---> Balíček kde-plasma-nm-openvpn.x86_64 0:0.9.3.4-4.20140520git043bbae.fc20 bude smazán
---> Balíček kde-plasma-nm-pptp.x86_64 0:0.9.3.4-4.20140520git043bbae.fc20 bude smazán
---> Balíček kde-plasma-nm-vpnc.x86_64 0:0.9.3.4-4.20140520git043bbae.fc20 bude smazán
---> Balíček libnm-gtk.x86_64 0:0.9.9.0-10.git20140123.fc20 bude smazán
---> Balíček libnm-qt.x86_64 2:0.9.8.2-1.201404225cff3c5.fc20 bude smazán
---> Balíček nm-connection-editor.x86_64 0:0.9.9.0-10.git20140123.fc20 bude smazán
--> Kontrola transakce spuštěna
---> Balíček initial-setup.noarch 0:0.3.10.1-1.fc20 bude smazán
---> Balíček webkitgtk3.x86_64 0:2.2.7-1.fc20 bude smazán
--> Zpracování závislostí: libwebkitgtk-3.0.so.0()(64bit) pro balíček: 1:yelp-3.10.1-1.fc20.x86_64
--> Zpracování závislostí: libwebkitgtk-3.0.so.0()(64bit) pro balíček: 1:yelp-libs-3.10.1-1.fc20.x86_64
--> Kontrola transakce spuštěna
---> Balíček yelp.x86_64 1:3.10.1-1.fc20 bude smazán
--> Zpracování závislostí: yelp pro balíček: easytag-2.2.3-1.fc20.x86_64
---> Balíček yelp-libs.x86_64 1:3.10.1-1.fc20 bude smazán
--> Kontrola transakce spuštěna
---> Balíček easytag.x86_64 0:2.2.3-1.fc20 bude smazán
--> Řešení závislostí dokončeno

Závislosti vyřešeny.

===============================================================================================================================================================================================================
 Package                                                  Arch                                 Verze                                                             Repozitář                                Vel.
===============================================================================================================================================================================================================
Odstraňuje se:
 NetworkManager                                           x86_64                               1:0.9.9.0-41.git20131003.fc20                                     installed                               4.7 M
 NetworkManager-glib                                      x86_64                               1:0.9.9.0-41.git20131003.fc20                                     installed                               927 k
 NetworkManager-l2tp                                      x86_64                               0.9.8.6-1.fc20                                                    @updates                                336 k
 NetworkManager-openconnect                               x86_64                               0.9.8.0-2.fc20                                                    @anaconda                               694 k
 NetworkManager-openswan                                  x86_64                               0.9.8.4-2.fc20                                                    @updates                                268 k
 NetworkManager-openvpn                                   x86_64                               1:0.9.9.0-0.1.git20140128.fc20                                    @updates                                664 k
 NetworkManager-pptp                                      x86_64                               1:0.9.8.2-3.fc20                                                  @anaconda                               461 k
 NetworkManager-vpnc                                      x86_64                               1:0.9.8.2-2.fc20                                                  @anaconda                               435 k
Odstranění kvůli závislostem:
 anaconda                                                 x86_64                               20.25.16-1.fc20                                                   @updates                                8.5 M
 easytag                                                  x86_64                               2.2.3-1.fc20                                                      installed                               3.4 M
 geoclue                                                  x86_64                               0.12.99-5.fc20                                                    @fedora                                 335 k
 initial-setup                                            noarch                               0.3.10.1-1.fc20                                                   @anaconda                               124 k
 kde-plasma-nm                                            x86_64                               0.9.3.4-4.20140520git043bbae.fc20                                 @updates                                2.9 M
 kde-plasma-nm-l2tp                                       x86_64                               0.9.3.4-4.20140520git043bbae.fc20                                 @updates                                164 k
 kde-plasma-nm-openconnect                                x86_64                               0.9.3.4-4.20140520git043bbae.fc20                                 @updates                                163 k
 kde-plasma-nm-openswan                                   x86_64                               0.9.3.4-4.20140520git043bbae.fc20                                 @updates                                 89 k
 kde-plasma-nm-openvpn                                    x86_64                               0.9.3.4-4.20140520git043bbae.fc20                                 @updates                                332 k
 kde-plasma-nm-pptp                                       x86_64                               0.9.3.4-4.20140520git043bbae.fc20                                 @updates                                130 k
 kde-plasma-nm-vpnc                                       x86_64                               0.9.3.4-4.20140520git043bbae.fc20                                 @updates                                227 k
 libnm-gtk                                                x86_64                               0.9.9.0-10.git20140123.fc20                                       @updates                                215 k
 libnm-qt                                                 x86_64                               2:0.9.8.2-1.201404225cff3c5.fc20                                  @updates                                1.7 M
 nm-connection-editor                                     x86_64                               0.9.9.0-10.git20140123.fc20                                       @updates                                5.1 M
 webkitgtk3                                               x86_64                               2.2.7-1.fc20                                                      @updates                                 42 M
 yelp                                                     x86_64                               1:3.10.1-1.fc20                                                   @fedora                                 2.3 M
 yelp-libs                                                x86_64                               1:3.10.1-1.fc20                                                   @fedora                                 255 k

Shrnutí transakce
===============================================================================================================================================================================================================
Odstranění  8 Balíček (+17 Závislých balíčků)

Nainstalovaná velikost: 77 M
V pořádku [a/N]:

hmmmm ... no ... když já mám ten easytag docela rád ...

[pavlix]

Možná by bylo fajn buď neodstraňovat NetworkManager-glib, který v podstatě ničemu nevadí, nebo odstranit ty závislosti. Stejně je blbost, aby každá aplikace komunikovala s NetworkManagerem.

[kavol]

Možná by bylo fajn buď neodstraňovat NetworkManager-glib, který v podstatě ničemu nevadí,

neměla by otázka znít spíše pro co je skutečně potřeba, než čemu nevadí?

nebo odstranit ty závislosti. Stejně je blbost, aby každá aplikace komunikovala s NetworkManagerem.

můžeš se realizovat, jednak coby znalec NM jistě nahlásíš problém kvalitněji, nejlépe rovnou s patchi, a jednak já si dnes již kvótu bugů splnil, ba i překročil :-p

[pavlix]

neměla by otázka znít spíše pro co je skutečně potřeba, než čemu nevadí?

To bys asi měl řešit s maintainery těch konkrétních balíků. Mně osobně se přesně z tohoto důvodu víc líbí princip zdrojové distribuce s use flagy než konzumace hotových balíků. Ale to má zase jiné nevýhody. Binary distribution friendly řešení je velice jednoduché a mám ho v hlavě už delší dobu. Jedná se o knihovnu s dynamickými moduly z nichž jeden bude založený na NetworkManageru (a ideálně distribuovaný s NetworkManagerem), zatímco tvrdá závislost aplikací by byla jenom na té knihovně. Ale nemám chuť na sebe uvázat další správné řešení, které ve skutečnosti nikdo nechce.

můžeš se realizovat, jednak coby znalec NM jistě nahlásíš problém kvalitněji

Problém je v tom, že mě přítomnost NetworkManager-glib nevadí a typicky ani neodinstalovávám nic ze standardní instalace, jen pokud potřebuju, NetworkManager vypnu. O tohle by se asi měli především starat ti, kterým na tom nějak záleží.

[ukarr]

To neznáte Fedoru:

Dependencies Resolved

====================================================
 Package                             Size
====================================================
Removing:                         
 NetworkManager-glib                943 k
Removing for dependencies:        
 GREYCstoration-gimp                247 k
 ekiga                               18 M
 evolution                           37 M
 evolution-data-server               13 M
 gedit                               14 M
 gedit-plugins                      4.2 M
 geoclue                            307 k
 gimp                                60 M
 gimp-data-extras                   7.6 M
 gimp-fourier-plugin                 18 k
 gimp-help                           36 M
 gimp-help-browser                   59 k
 gimp-lqr-plugin                    920 k
 gimp-resynthesizer                  59 k
 gnome-online-accounts              3.7 M
 libgdata                           1.5 M
 libnm-gtk                          217 k
 libpeas                            417 k
 nm-connection-editor               5.1 M
 seed                               609 k
 simple-scan                        1.1 M
 surf                               183 k
 system-config-users-docs           1.6 M
 webkitgtk                           40 M
 webkitgtk3                          40 M
 xsane-gimp                         687 k
 yelp                               2.3 M
 yelp-libs                          248 k
                                  
Transaction Summary               
====================================================
Remove  1 Package (+28 Dependent packages)

Installed size: 291 M
Is this ok [y/N]: n

[tacoberu]

No, máš dvě možnosti: 1. buď se s tím smířit a být zticha 2. nebo to nahlásit fedoře jako bug balíčku, případně můžeš upravit balíčky sám

[ukarr]

Díky za radu, ale možností mám spoustu, ne jen ty dvě zmíněné, co jsou vlastně tři. Třeba to mohu postnout na abclinuxu.cz, aby si uživatelé jiných distribucí udělali obrázek o Fedoře.

[jadd]

yum remove --nodeps balík Taky mám s tímto (tvým) prováděním odinstalace chápací problémy..proč to je ve výchozím a ne naopak. Je to jako by rm bylo nastaveno na rm -rf *.

[pavlix]

Osobně to vidím naopak, yum má za úkol udržovat systém v konzistentním stavu, což --nodeps jaksi narušuje. Základním nástrojem je navíc rpm, který bez stejnojmenného přepínače odmítne balíček odinstalovat, pokud by se tím systém dostal do nekonzistentního stavu.

[jadd]

poslední oficiální dokumentace v.12 http://docs.fedoraproject.org/en-US/Fedora/12/html/Deployment_Guide/index.html možná by bylo potřeba, začátečníkům zdůrazňovat, že mají používat rpm když je to základní nástroj.

[pavlix]

možná by bylo potřeba, začátečníkům zdůrazňovat, že mají používat rpm když je to základní nástroj.

Možná i proto by ho začátečníci používat neměli. Ale především by podle mě neměli používat ani yum remove --nodeps, ale měli by udržovat svůj systém v konzistentním stavu.

[vain]

Nemůžeš říct, že jsi se nesnažil

[Peter Golis]

Ja mám statickú konfigurácou siete v /etc/netctl/static, a funguje bez problémov. Takže súhlasím s prívlastkom.

[Petr Ježek]

Přesně, nechápu, co je na perfektně funkční statické konfiguraci sítě za problém kromě faktu, že se musí vědět how to...

[Peter Golis]

Howto je potrebné aj na zapnutie mikrovlnnej trúby. Každý model má inak spravené ovládanie a nie každý pochopí ktorý ideogram znamená Štart.

[pavlix]

Byl jsem u známých v Berlíně a zůstal jsem tam přes den jenom s tátou, který spal, pizzou, která potřebovala ohřát a nějakou šílenou multifunkční troubou s německým UI. Když přišli domácí, řekli mi, že jsem měl štěstí, že jsem netrefil program na ohřívání párou.

[vain]

Myslím, že i parní trouba by tu pizzu zvládla, jen by byla jako bys ji protáhl myčkou, ale teplá by byla taky

[pavlix]

Dobrou chuť ;).

[Josef Kufner]

Se divím, že nikdo ještě nevytáhl poštovní holuby.

[Petr Ježek]

Na převažujících instalacích s GUI celkem zbytečnost, na starých strojích a serverech celkem rozumný počin. Ostatně NM je používán vždy, když není spokojenost s defaultem, což nastává celkem často. Kdo si pomáhá sktipty, musí počítat s jejich obtížným systémovým řízením a nenadávat na předem zcela jasné.

[pavlix]

Jsem asi staromilec a používám tunu konzolových nástrojů i na notebooku s GUI. Navíc zrovna u sítí mi GUI připadá nedostatečně flexibilní.

[AsciiWolf]

+1

[drunkezz]

musim tu spomenut jednu vec...

klasicka situacia co sa deje v datacentre 100x denne.. donesies si laptop pichnes sa di switcha a potrebujes rychlo nahodit ip z vlan ip range...  tak ides ip a a xxx.xx.xxx.xxx/24 dev eth0 vsetko frci...ale len 15 sekund kym network manager neviem co spravi ale zhodi ten interface resp adresu dole....preco? cakal by som ze to bude inteligentnejsie a setnutu ipku necha na pokoji

D.

[pavlix]

Ve zprávičce v jejímž kontextu reaguješ, je takový odkaz, přes který se dostaneš na blogový zápisek o popisované verzi NetworkManageru. Bylo by fajn, kdybys mu věnoval dvě minutky namísto psaní nesmyslů do diskuzí. Pokud by ale skutečně v 0.9.10 byla chyba, která by způsobovala problém s výše uvedenou konfigurací, bylo by fajn to reportovat na bugzilla.gnome.org s přesným popisem, jak chybu reprodukovat.

[drunkezz]

tyyy to  pomohlo. dik:)
D.

[pavlix]

Jinak se omlouvám za mírně konfrontační tón, ale skutečně mi přijde zvláštní pod zprávičkou o konkrétní verzí reagovat jako kdyby ta verze vůbec nevyšla. Nová verze samozřejmě není dokonalá, na to je NetworkManager příliš velká příšera (beast), ale mám takový dojem, že srovnání se s existující a za běhu přidanou konfigurací je hlavním účelem tohoto vydání.

Už jen proto by bylo dobré novou verzi nebo alspoň v git master tyhle problémy řádně otestovat, protože máloco funguje na první pokus. Dokonce mám pocit, že tam kluci udělali i nějakéto špatné rozhodnutí, ale bylo by dobré kdyby na to upozorňovali i jiní lidé než věčný hnidopich Šimerda, a to především lidé z provozu.

[drunkezz]

jj moja chyba.. to vies provisioning bezi...firewall blokuje vseti tu cakaju na nove servery...a tak si v dvojminutke pokoja odskocis na abc aby si si zdvyhol ego a pofrflal.... jasna blbost....takze ako pisem vyssie ozaj diki..precitat si ten blog mi vyrazne zlepsilo naladu

D.

[pavlix]

Zrovna 0.9.10 je pro mě tak trochu srdeční záležitost, protože obsahuje spoustu věcí, které jsem navrh nebo implementoval. Loni jsem měl na toto téma přednášku jak v češtině, tak v angličtině, ale trvalo ještě více než rok, než mohl vzniknout nový release.

Z bugzilly je zjevné, že má následovat release 1.0, takže by bylo dobré, kdyby všichni co nejdříve verifikovali novou funkcionalitu 0.9.10 a hlásili chyby především v upstreamové bugzille, aby až vyjde 1.0, byly ty výsledky nějak usazené. Bylo by fajn, kdyby výhrady přišly pokud možno co nejdříve.

[drunkezz]

zamyslam sa este nad jednou vecou...v pripade ze verzie < 0.9.10 maju taky zavazne nedostatky, ja len nerozumiem preco sa dostavaju do produkcnych vetiev distribucii....pavlix pls leakni nieco ohladom tohto rozhodovania

D.

[pavlix]

preco sa dostavaju do produkcnych vetiev distribucii...

Je to prosté. V době, kdy se starší verze dostávaly do distribucí, novější verze ještě nebyly. Bavíme se zde o velmi čerstvé verzi, která sice přináší dlouho očekávané vlastnosti, ale jejíž chyby zatím nebyly dobře prozkoumány. Věřím, že i stabilní větev 0.9.10 bude mít několik opravných vydání. Fedora je v tomhle trochu výjimkou a testuje na lidech snapshoty z gitu, vzhledem k tomu, že maintaineři jsou zároveň upstreamovými vývojáři.

[Vantomas]

Ono teda to, že NM (nebo něco kolem něj) maže ručně přidané IP adresy, když se nedaří získat IP přes DHCP, není vlastnost, ale bug? Protože toto chování mě celkem dost ničí a ještě teď ve Fedora 20 co se vyměnil v KDE plasmoid pro NM, tak už tam ani není zaškrtávátko pro vypnutí NM.

[pavlix]

Ono teda to, že NM (nebo něco kolem něj) maže ručně přidané IP adresy, když se nedaří získat IP přes DHCP, není vlastnost, ale bug?

Takhle, před releasem 0.9.10 by se dalo říci, že je to vlastnost, protože úkolem NetworkManageru bylo slepě aplikovat svou představu o konfiguraci adres daného rozhraní do kernelu. Release 0.9.10 má mezi oznámenou funkcionalitou příjem kernelových změn do běhové představy NetworkManageru. Tudíž od 0.9.10 dále by to už byl jednoznačně bug.

Protože toto chování mě celkem dost ničí a ještě teď ve Fedora 20 co se vyměnil v KDE plasmoid pro NM, tak už tam ani není zaškrtávátko pro vypnutí NM.

NetworkManager je normální služba a vypíná se pomocí systemd. Na druhou stranu Fedora už delší dobu obsahuje různé snapshoty NetworkManageru z gitu, takže tam nepotkáš čistou upstream verzi a nové vlastnosti byly dostupné daleko dřív než v upstreamu. Při troše snahy by měl jít NetworkManager >= 0.9.10 ovládnout do té míry, aby nebylo nutné ho vypínat, a ve verzi 0.1 bych očekával vyladěné zásadní problémy objevené během používání 0.9.10.

Jak už jsem psal jinde, doporučuju 0.9.10 vyzkoušet a co nejdříve ověřit, zda vyhovuje požadavkům a hlásit všechny zásadní problémy v upstream bugzille.

[Vantomas]

Takhle, před releasem 0.9.10 by se dalo říci, že je to vlastnost, protože úkolem NetworkManageru bylo slepě aplikovat svou představu o konfiguraci adres daného rozhraní do kernelu. Release 0.9.10 má mezi oznámenou funkcionalitou příjem kernelových změn do běhové představy NetworkManageru. Tudíž od 0.9.10 dále by to už byl jednoznačně bug.

Tak to je paráda. To se těším na upgrade. Teď mám 0.9.9.0-39.git20131003.fc20 a chová se to teda tak jak jsem popisoval.

NetworkManager je normální služba a vypíná se pomocí systemd. Na druhou stranu Fedora už delší dobu obsahuje různé snapshoty NetworkManageru z gitu, takže tam nepotkáš čistou upstream verzi a nové vlastnosti byly dostupné daleko dřív než v upstreamu. Při troše snahy by měl jít NetworkManager >= 0.9.10 ovládnout do té míry, aby nebylo nutné ho vypínat, a ve verzi 0.1 bych očekával vyladěné zásadní problémy objevené během používání 0.9.10.

No ve starém plasmoidu bylo zaškrtávátko "Povolit síťování", které přesně řešilo to, že když jsem do toho chtěl sahat ručně, toto to umožnilo. V novém toto není a je to opruz se zastavováním služby. Ale chápu, že jak je oddělený vývoj a release do distribucí jednou za čas, tak se prostě taková věc stane - z plasmoidu odstranili, protože NM už je přece opravený, ale ouha, v distru je ještě historická verze co zlobí

Jak už jsem psal jinde, doporučuju 0.9.10 vyzkoušet a co nejdříve ověřit, zda vyhovuje požadavkům a hlásit všechny zásadní problémy v upstream bugzille.

Přiznám se teda, že z dob kompilování a štelování v Gentoo jsem trochu zpohodlněl a tak i za ceny snížení starostí raději počkám na další release ve Fedoře.

[pavlix]

No ve starém plasmoidu bylo zaškrtávátko "Povolit síťování"

To bude nejspíš něco ve smyslu nmcli networking off, a to opravdu nemá smysl volat z GUI, když je stejně dalším krokem přepnutí do konzole.

Přiznám se teda, že z dob kompilování a štelování v Gentoo jsem trochu zpohodlněl a tak i za ceny snížení starostí raději počkám na další release ve Fedoře.

A co třeba testnout verzi z rawhide, pokud je kompatibilní co do závislostí? Všiml jsem si, že je rawhide v tomhle trošku flexibilnější a dokonce jsme nedávno museli vyžádat release -41 právě kvůli tomu, že nám z hlediska integrace dnssec-trigger chyběla jedna z oprav, které už v gitu byly.

[Vantomas]

To bude nejspíš něco ve smyslu nmcli networking off, a to opravdu nemá smysl volat z GUI, když je stejně dalším krokem přepnutí do konzole.

No jo, jenže zjišťovat to někde, když to znám jen ze zaškrtávátka a pak mi ho seberou... NM jsem praticky nastavoval jen z GUI, protože nmcli byla vytěsněná hrůzověc a jiný nástroj neexistoval.

A co třeba testnout verzi z rawhide, pokud je kompatibilní co do závislostí? Všiml jsem si, že je rawhide v tomhle trošku flexibilnější a dokonce jsme nedávno museli vyžádat release -41 právě kvůli tomu, že nám z hlediska integrace dnssec-trigger chyběla jedna z oprav, které už v gitu byly.

Tak jsem doplnil rawhide repo, pak zkusil yum --enablerepo=rawhide update NetworkManager a zhrozil jsem se, k tomu se to tam blokuje kolem balíčků na kterých závisí Chromium, takže prý --skip-broken a teda zhodnotil bych to tak, že -fc21 zatím nechci.

[pavlix]

Njn, stane se.

[kavol]

Tak jsem doplnil rawhide repo, pak zkusil yum --enablerepo=rawhide update NetworkManager a zhrozil jsem se, k tomu se to tam blokuje kolem balíčků na kterých závisí Chromium, takže prý --skip-broken a teda zhodnotil bych to tak, že -fc21 zatím nechci.

no, to se dělá tak, že z rawhide vezmeš jen zdroják (srpm) a překompiluješ si ho k obrazu svému ...

(pozn. platnost odkazu tuším 30 dní nebo za jak dlouho se maže bordel)

(achjo, to fakt musím nacházet bugy úplně ve všem, cokoliv se pokusím udělat? :-/ )

[kolcon]

no, musim teda rict, ze ten nmtui vypada skvele!

[R]

Prave s NetworkManagerom bojujem a nadavam. Snazim sa docielit, aby fungoval 3G modem automaticky - tzn. po nabootovani systemu sa pripoji a ak sa spojenie prerusi, tak sa pripoji znovu. Zda sa, ze je to pre NetworkManager nezvladnutelny ukon... Autoconnect nefunguje - modem sa po boote nepripoji. Po "nmcli nm wwan off" a "nmcli nm wwan on" sa pripoji. Po dalsom "nmcli nm wwan off" sa to uz nikdy nepripoji, musim modem odpojit od napajania (kto vie, co mu to posiela...)

Takze musim nasadit stare dobre skripty a pppd...

[pavlix]

Prave s NetworkManagerom bojujem a nadavam. Snazim sa docielit, aby fungoval 3G modem automaticky - tzn. po nabootovani systemu sa pripoji a ak sa spojenie prerusi, tak sa pripoji znovu. Zda sa, ze je to pre NetworkManager nezvladnutelny ukon... Autoconnect nefunguje - modem sa po boote nepripoji.

Rád bych se tě zeptal, zda jsi to testoval. Dívám se do bugzilly a problémy, o kterých zde píšeš, jsou označené jako vyřešené. Pokud jsi tyto bugy skutečně v 0.9.10 reprodukoval, bylo by dobré je znovu otevřít.

Po "nmcli nm wwan off" a "nmcli nm wwan on" sa pripoji.

Pokud to správně chápu, tak to je klasický workaround, který by už neměl být potřeba.

Po dalsom "nmcli nm wwan off" sa to uz nikdy nepripoji, musim modem odpojit od napajania (kto vie, co mu to posiela...)

Měl jsem podobné problémy se svým telefonem připojeným kabelem, ale ten problém se projevoval i bez NetworkManageru, zjevně to bylo v kernelu. Na druhou stranu pokud se ti nedaří najít příčinu, může mít smysl to hlásit normálně na NetworkManager s detailním popisem, identifikací zařízení a předevšlím logy.

Takze musim nasadit stare dobre skripty a pppd...

Osobně dávám přednost alespoň wvdial, přímou konfiguraci pppd jsem si nikdy neoblíbil. Ten problém se zmatením modemu do té míry, že ho musíš restartovat, ten se s pppd neprojevuje? Čert ví, na co ten modem takto reaguje. Pokud je to nějaký častější modem, podrobný bug report by se hodil.

[R]

Tento novy NetworkManager som neskusal a ani skusat nebudem, pretoze pouzivam distribucny 0.9.4 a kompilovat nic nebudem.

Modem je Huawei E220, ten sa predaval hadam vsade a pozna ho kazdy (je o nom aj clanok na Wikipedii). S pppd normalne funguje. S NetworkManagerom 0.8 (na inom stroji) funguje tiez.

Odladene skripty na LAN + 3G modem s pppd mam, bezia niekolko rokov v produkcnej prevadzke. Takze je pre mna jednoduchsie ich pouzit znovu ako dalej riesit, preto NetworkManager nefunguje.

[pavlix]

Tento novy NetworkManager som neskusal a ani skusat nebudem, pretoze pouzivam distribucny 0.9.4 a kompilovat nic nebudem.

Když jsem se poprvé hrabal v kódu NetworkManageru, bylo to právě v době stable větve 0.9.4, a nastupoval jsem do RH s tím, že jdu do projektu, na kterém je práce jak na kostele. Nerad bych se k tehdejšímu stavu vracel.

Modem je Huawei E220

Ten jsem snad měl i v ruce.

S NetworkManagerom 0.8 (na inom stroji) funguje tiez.

S tím bych si už vůbec nechtěl špinit ruce a po celou dobu práce pro redhatí NM tým se mi podařilo se tomu i vyhnout. Ví se nějak v čem je problém? Funguje dobře s aktuální verzí? Pokud není ani známý status podpory v git master, nemá smysl zabývat se jeho fukcí o tři vydání nazpět.

[filbar]

Když se tu tak rozjela diskuse o NM, tak mám jeden dotaz - lze nějak zařídit, aby to píchnutí USB 3G modemu se mě to potom co se mě to aumaticky zeptá, také automaticky připojilo přes ten 3G model a nemusel jsem ručně lézt do nm menu a připojivat to?

[pavlix]

Nemělo by u NetoworkManageru >= 0.9.10 stačit nastavit u dané connection automatické připojování?

[Jindřich Makovička]

To trochu pomůže, ale s 0.9.8 se mi desktop s USB wifi donglem pořád připojuje na domácí síť zhruba v 9 případech z deseti. Občas je prostě potřeba vlézt do menu, kliknout na connect to hidden network a ručně si to připojení znova vynutit.

Pravděpodobnosti trochu pomohlo přidání wifi ovladače do /etc/modules, tj. zřejmě je tam race condition, kdy se po bootu nestihne dongle včas inicializovat a NM už se znova připojit nezkusí.

[pavlix]

To trochu pomůže, ale s 0.9.8 se mi desktop s USB wifi donglem pořád připojuje na domácí síť zhruba v 9 případech z deseti.

Ještě před chvílí byla řeč o USB modemu...

Občas je prostě potřeba vlézt do menu, kliknout na connect to hidden network a ručně si to připojení znova vynutit.

A je ta síť skutečně skrytá nebo je to jenom workaround?

Pravděpodobnosti trochu pomohlo přidání wifi ovladače do /etc/modules, tj. zřejmě je tam race condition, kdy se po bootu nestihne dongle včas inicializovat a NM už se znova připojit nezkusí.

Takže problém může být od kernelu přes udev až po NetworkManager. Tohle by bylo určitě dobré nahlásit včetně logů.

[odin]

Takže problém může být od kernelu přes udev až po NetworkManager. Tohle by bylo určitě dobré nahlásit včetně logů.

Mrzi mne to, ale musim si povzdechnout, kam se omg dostal GNU/Linuxovy desktop? Je opravdu 21. stoleti, ze se uzivatel docka takoveto rady? Tim nechci rypat do pavlixe, ten dela z jisteho uhlu pohledu zasluznou praci.

Drive jsem byl takovy Linuxovy misionar a snazil jsem se na spravny system obratit spoustu lidi ve svem okoli. U nekterych to vyslo a zustali. U nekterych to nevyslo a naopak jsem byl sam za idiota. Je treba si uvedomit, ze normalniho cloveka reportovani bugu vubec nezajima. Vetsinou ani nevi, o co se jedna, a i kdyby to nakrasne vedel, tak tomu nebude venovat svuj cas. Je to smutne, ale dnes uz nikomu GNU/Linux na desktop nedoporucuji, nechci se stydet za to, ze komunita nebyla schopna do 21. stoleti vyv[iy]nout funkcni desktop, na ktery je spoleh.

[sid1]

Clovek co je tu zrejme nie je bezny uzivatel ktory povacsine netusi ani co je desktop iba vie kde ma kliknut mysou ked chce pustit facebook. Ak chces system starajte sa tak mas komercne distro od toho. Ci ako niekto ma travit a stracat svoj cas na tvojom probleme ale hlavne nech ta neotravuje?

[Odin]

Obavam se, ze jsi mne nepochopil...

[pavlix]

Mrzi mne to, ale musim si povzdechnout, kam se omg dostal GNU/Linuxovy desktop?

Až na nějaká ta škobrtnutí se za posledních deset let všechno ohromně zautomatizovalo a zjednodušilo. Když jsem s linuxovým desktopem začínal, tak jsem si ani neškrtl bez konfigurace X a bez detailní znalosti režimů monitoru, které na něm často ani nebyly popsány.

Dneska na linuxovém desktopu funguje spousta věcí lépe než na Windows, často nezávisle na konkrétním použitém hardware a především bez nebezpečných samoinstalačních balíčků.

uzivatel docka takoveto rady?

Ona je to dobrá rada a získat ty logy není nijak složité, navíc se nejedná o žádného obyčejného uživatele, ale o člověka, který se hrabe v /etc/modules.

Je treba si uvedomit, ze normalniho cloveka reportovani bugu vubec nezajima.

To je nesmysl, uživatelé jakéhokoliv druhu chyby hlásí, pokud věří, že jsou odstranitelné, jde jen o to komu a jakým způsobem je hlásí. Pokud to bude moje matka, pravděpodobně bude hlásit chybu mně formou názorné ukázky přímo u počítače a tím to pro ni končí. Pokud to bude v práci, bude chybu hlásit dostupnými kanály v práci.

To, že má každý člověk schopný napsat pár vět anglicky možnost hlásit chyby přímo do distribucí a upstreamu, považuju za obrovskou výhodu. Možnost bavit se o chybách ve vlastním jazyce ať už na Fedora.cz nebo při troše snahy i na Abclinuxu.cz považuju za hotový luxus, zvláště pro ty, kteří angličtinu moc neovládají.

tak tomu nebude venovat svuj cas.

Pokud tomu nebude věnovat svůj čas, tak o tom my nebudeme ani vědět. Je zvláštní, kolik je člověk schopný problému věnovat jalového času, když je mu za těžko dát pár minut času užitečného.

Je to smutne, ale dnes uz nikomu GNU/Linux na desktop nedoporucuji, nechci se stydet za to, ze komunita nebyla schopna do 21. stoleti vyv[iy]nout funkcni desktop, na ktery je spoleh.

Tím jsem si prošel už dávno.

[Spike]

Ještě bych navázal na ty normálního uživatele - taky je nezajímá tunění bashových skriptů pro (polo)automatickou konfiguraci (Wifi) sítí, připojování USB disků, startování služeb apod.

Myslím, že lidi od Fedory (a vůbec všech projektů, na kterých to stojí (a padá)) třeba dělají hodně dobrou práci. Před časem jsem hodil Rawhide ve virtualu a pak F20 na IdeaPadu S12 (s Via Nano - takže bohužel nevyvíjený openchrome bez podpory OpenGL a HW dekódování videa z toho dělá nepoužitelný systém) a z hlediska UI/UX už se linuxový desktop vážně nemá moc za co stydět. Od instalace po uživatelskou konfiguraci.

[pavlix]

Ještě bych navázal na ty normálního uživatele - taky je nezajímá tunění bashových skriptů pro (polo)automatickou konfiguraci (Wifi) sítí, připojování USB disků, startování služeb apod.

+1

[odin]

Bohuzel na jednom stroji jsem v situaci, kdy poloautomaticky skript funguje perfektne, ale super automaticky nm nefunguje prakticky vubec.

[pavlix]

Řeč byla o uživateli pod hranicí člověka schopného napsat bug report, tak jaképak skripty?

[Marián Kyral]

uživatelé jakéhokoliv druhu chyby hlásí, pokud věří, že jsou odstranitelné

A nebude tady ten pes zakopán? Někdy prostě nemám tu potřebu být napadán, že jsem blbec a že jediná správná (TM) cesta je ta, kterou si vývojáři vybrali. Viz třeba slavný file dialog v GTK. Fakt je tak těžké pochopit, že některé operace je rychlejší udělat přímo ve file open/save dialogu, než startovat jinou aplikaci a znova hledat adresář, kde chci danou akci provést?

Třeba, když vytvořím nový adresář a ve jméně udělám překlep. V GTK save dialogu s tím už nic neudělám: Bug 325150 - Save As dialog cannot delete or rename files - nahlášeno před osmi lety a furt nic

[ukarr]

+1

[pavlix]

A nebude tady ten pes zakopán?

To je ale přesně důvod, proč jsem to napsal, jak jsem to napsal. Lidé se liší v tom, co a proč jsou ochotni dělat, ale zpravidla se shodují v tom, že se snaží dělat to, co má podle nich nějaký smysl.

Někdy prostě nemám tu potřebu být napadán, že jsem blbec a že jediná správná (TM) cesta je ta, kterou si vývojáři vybrali.

Zatímco vývojáři často nemají na výběr, zda budou napadáni a taky to přežijí. Je to jen otázka přístupu a volby.

Viz třeba slavný file dialog v GTK

Hlásit bugy na netriviální UI problémy mě taky moc nebaví, ale čas od času se odhodlám. Něco jiného je, když už takový bug existuje nebo existuje nějaký jasný statement, že to takhle projekt chce. Pak bych se s tím buď smířil nebo hledal možnost spouštění alternativního file dialogu. Na první pohled to vypadá, že je ten bug report zbytečný, ale nareportované to je, víš, na čem jsi, a kdyby se stal zázrak a Gnome začal bugy nějak promptně řešit, je to připravené.

U NetworkManageru k takovému malému zázraku došlo a spousta mnoho let starých bugů je buď vyřešena, nebo alespoň nějak smysluplně okomentována. Bugy jsou najednou rozdelené do komponent, aby se případní dobrovolník mohl probrat seznamem o desítkách ticketů v oblasti, které ho zajímá namísto seznamem o stovkách ticketů. Navíc je potřeba udržovat v dobré stavu bugzillu alespoň některých klíčových projektů, aby bylo srovnání pro ty projekty, které nic takového nedělají.

[pavlix]

Jak se na to tak dívám, tak tam není žádná silná opozice a poslední patch je někdy z roku 2009. Podle mě by stálo za to mít k dispozici udržovaný patch v některé distribuci a jeho aktuální verzi držet v bugzille. Já ovšem ani nepoužívám Gnome.

[Marián Kyral]

Taky mám jen pár GTK aplikací. Gimp, Rawtherapee, Firefox a Thunderbird. Nejvíce mne to štve v TB, když chci soubor před přiložením přejmenovat (ale to je open file dialog a tedy jiný bug ). Kdysi jsem používal kgtk - rouboval KDE file dialogy do gtk aplikací. Nefungovalo to vždy a momentálně už není projekt udržován. Tak jsem se s tím holt smířil a u gtk file dialogů už jen tiše nadávám.

Přiložený patch jsem nezkoušel a v gtk se momentálně hrabat nehodlám.

[pavlix]

To chápu.

[Lol Phirae]

Podle mě by stálo za to mít k dispozici udržovaný patch v některé distribuci a jeho aktuální verzi držet v bugzille. Já ovšem ani nepoužívám Gnome.

Mně ty reakce "vývojářů" přijdou naprosto neuvěřitelné.

- Nehrábli ani prstem

- Někdo napsal patch

- Opět nehrábli ani prstem, dokonce ani nejsou ochotni sami vytvořit branch v gitu a čekají, až to za milostpány někdo udělá?!

- Po pár letech hekají jak rozmazlení fracci, že patch je již neudržovaný a ať ostatní kurva pohnou prdelí a opět to zaktualizují?

A jste si jako asi tak mysleli? Že to bude někdo portovat deset let, než se uráčíte pohnout prdelí a milostivě to commitnout? OMG, co to je za klauni?

[pavlix]

Mně ty reakce "vývojářů" přijdou naprosto neuvěřitelné.

Gnome je trochu speciální případ. Nějakou dobu jsem se tím zabýval a pak jsem usoudil, že nejlepším řešením pro mě osobně je Gnome 3 nepoužívat a i u aplikací být opatrný. Bohužel, stejně jako je tomu u dalších projektů, má tento zvláštní typ vývojářů vliv i mimo samotný projekt.

A jste si jako asi tak mysleli?

Proč používáš druhou osobu, nikdo ze zůčastněních kromě Mariána (který je na světlé straně) se zde na Abclinuxu nepohybuje a dost možná ani neumí česky. Údržba patchů po delší dobu je věc, kterou v podobných případech aplikuju já a pokud se do toho člověku chce, považuju to za dobrý nápad. Ostatně ve větším měřítku takto fungují stabilnější distribuce.

[Lol Phirae]

Ale to vůbec nebylo myšleno na tebe... pardon. Akorát jsem se opět nasral, přemýšlím, jestli jim to tam jim mám jít taky připsat v angličtině (asi mám někde dokonce stále i login, ale již léta jsem to nepoužil, protože reportování do Gnome bugzilly je totální ztrátou času, krom toho nervy máme každý taky jen jedny, že...)

[pavlix]

Ale to vůbec nebylo myšleno na tebe...

Já se omlouvám, já jsem to tak ani nebral. Chápal jsem to jako do pléna těch, kteří zde diskutují a pak už jsem odpověděl jen za sebe.

Akorát jsem se opět nasral, přemýšlím, jestli jim to tam jim mám jít taky připsat v angličtině

Nevím, jestli má cenu v současné situaci šťourat do Gnome. Jednu dobu dokonce chtěli banovat za pouhé odkázání na jeden bugreport, který samozřejmě proletěl všemi linuxovýmé médii. Nemám zmapováno, jak moc a jakým způsobem se angažuje můj zaměstnavatel, takže zůstanu při tom, co jsem zde napsal ;).

krom toho nervy máme každý taky jen jedny, že...

To rozhodně.

[odin]

Až na nějaká ta škobrtnutí se za posledních deset let všechno ohromně zautomatizovalo a zjednodušilo. Když jsem s linuxovým desktopem začínal, tak jsem si ani neškrtl bez konfigurace X a bez detailní znalosti režimů monitoru, které na něm často ani nebyly popsány.

Je pravda, ze je spousta veci jednodussi a ze nyni existuje spousta klikatek pro bfu. Na druhou stranu zde mame problem s podporou hardwaru - treba wifi radice. Vim, ze to neni problem GNU/Linuxu, ale vyrobce toho daneho hw, ale to bezneho uzivatele zhola nezajima. A k tem monitorum. Je sice pravda, ze ve vetsine pripadu dnes jiz neni problem. Ale zrovna pred nekolika tydny jsem resil situaci, kdy si kamarad koupil novy lcd monitor, ktery mel patrne zabugovanou podporu DDC, a po pripojeni mu grafika nabehla v 800x600 a vetsi rozliseni to nenabidlo. Nechtel jsem se s tim moc parat, tak jsem ubuntu vymenil za debian testing a problem byl vyresen. Uzivetel ma pak ale opravnene obavy, ze kdyz ten super GNU/Linux, ktery je tak komunitou vychvalovan, nezvladne ani monitor, tak k jakym chybam a nedej boze ztrate dat muze dojit. To jsou slova onoho znameho.

Ona je to dobrá rada a získat ty logy není nijak složité, navíc se nejedná o žádného obyčejného uživatele, ale o člověka, který se hrabe v /etc/modules.

Myslel jsem to obecne. Cest tem, kteri jsou ochotni radit. Jen jsem si povzdechnul na situaci, ze je toto treba delat v 21. stoleti. Ohledne obtiznosti ziskani logu bych si dovolil polemizovat. Pral bych vam slyset, jak po telefonu naviguji uzivatele, aby mi poslal vystup z dmesg. Bohuzel ho to asi po trech minutach prestalo bavit a dnes je spokojen s windows. Lide nechteji system, kde musi lezt do pro ne oskliveho prikazoveho radku a posilat nekam nejake nesrozumitelne texty z buh vi jakych souboru. Opravdu to nechteji. Chteji system pouzivat, ne oznamovat jeho chyby.

To je nesmysl, uživatelé jakéhokoliv druhu chyby hlásí, pokud věří, že jsou odstranitelné,

Zname asi kazdy jiny okruh uzivatelu. Ti moji potrebuji system pouzivat a ne reportovat jeho chyby. Neni to nic proti GNU/Linuxu, ja jej pouzivam a mam jej rad, ale vysvetlujte to nekomu, kdo vam rekne, ze jeho cas je na takoveto hrani prilis drahy. Zajimave je, ze spousta techto lidi se vrati k windows a funguji spokojene a bez chyb a jejich reportovani...

Myslim, ze i z techto duvodu (nedodelky, chyby, tahnouci se bugy (viz gtk file open dialog) GNU/Linux nikdy nedosahne vyznamneho podilu na beznem desktopu (android na tabletech opravdu pocitat nebudu ). Treba je to dobre, ze v nasich radach nejsou 'uplne lamy', ale ja bych byl radsi, kdyz bych je v komunitnich radach videl. Osobne mam Linux moc rad a dokonce mne v posledni dobe zase zacalo bavit se v nem rypat a poznavat jej. Chapu ale, ze normalni uzivatel o toto nestoji a neoceni to.

[Marián Kyral]

Uzivetel ma pak ale opravnene obavy, ze kdyz ten super GNU/Linux, ktery je tak komunitou vychvalovan, nezvladne ani monitor, tak k jakym chybam a nedej boze ztrate dat muze dojit. To jsou slova onoho znameho.

Onen známý asi nikdy neměl windows ne? Tam je to přece úplně to samé. Někdy dokonce bíle na modré, případně ještě hůř, bíle na červené.

[odin]

Pouzival windows, ale tam prakticky zadne problemy nemel. Pak to takovemu cloveku vysvetlujte..

[Marián Kyral]

A to neviděl, kolik aktualizací řešící kritické chyby mu každé první úterý v měsíci MS tlačil? Strašné kolikrát mohl přijít o všechna svoje data. Takovému systému bych teda nevěřil

[pavlix]

Je pravda, ze je spousta veci jednodussi a ze nyni existuje spousta klikatek pro bfu.

Nemyslím si, že by to bylo jenom o klikátkách. Třeba s příkazem xrandr člověk může za běhu poladit zobrazovací zařízení dle libosti. Tato zprávička je o verzi, která mimojiné přináší smysluplné CLI rozhraní pro NetworkManager, který už předtím spoustě lidí ulehčil život. Naopak já osobně dávám přednost příkazovým nástrojům a dobře testovatelným postupům postaveným nad API, které pak ať si klidně používá GUI tool dostupný uživatelům zvyklým na Windows.

Uzivetel ma pak ale opravnene obavy, ze kdyz ten super GNU/Linux, ktery je tak komunitou vychvalovan, nezvladne ani monitor, tak k jakym chybam a nedej boze ztrate dat muze dojit. To jsou slova onoho znameho.

No když je člověk debil (to nemyslím zle, sám jsem ledacos ledaskomu doporučil) a všem okolo něco cpe, tak se pak nesmí divit, když se mu vrátí kritika.

Zname asi kazdy jiny okruh uzivatelu.

To si nemyslím a ani si nemyslím, že můžeš toto tvrzení nečím podpořit. Znám různé typy uživatelů s různými vzorci chování.

Neni to nic proti GNU/Linuxu, ja jej pouzivam a mam jej rad, ale vysvetlujte to nekomu, kdo vam rekne, ze jeho cas je na takoveto hrani prilis drahy.

To je velmi jednoduché. Můj čas je příliš drahý na to, abych to někomu vysvětloval. Pokud věnuju čas nesmyslům, tak jen a pouze ze své vlastní vůle. Pokud má někdo velký zájem, řeknu mu, co proč používám já, seznámím ho s užitečnými fakty.

Zajimave je, ze spousta techto lidi se vrati k windows a funguji spokojene a bez chyb a jejich reportovani...

Popravdě řečeno jsem v životě střídal systémy, distribuce a programy tolik, že jsem tenhle fenomén dokázal pozorovat sám na sobě. Zajímavé to rozhodně je, ale u mě to teda platilo na 100% a nezáleželo na tom z čeho na co zrovna přecházím. Zatím jsem vždy měnil software jen z vlastního rozhodnutí a z vlastních důvodů a sám jsem taky nesl zodpovědnost za celý přechod i případný návrat.

[pita]

Klasicky produkt korporatniho prostredi RH. Behemoth ktery spolyka funkcionalitu dostupou uz existujicimi nastroji a misto wrapperu nad nimi si to od zakladu musi napsat sam. Vysledkem jsou konflikty pokud nevypnete jedno nebo druhe (trpka zkusenost z openSUSE). Do verze 0.7.neco se sit ani nenastavila az po prihlaseni usera (nebyl bug ale featura jak z dob starych windows). Do verze 0.8.neco existovalo jen graficke nastavovatko, terminal asi neni dost enterprise.

Ja vim, co bolo to bolo, terazky som majorom, ale spatnou zkusenost uz nevymazu …

[pavlix]

Jo, to jsem s klukama taky probíral a navrhoval jsem NetworkManager přejmenovat. Dobře načasovaná změna jména by umlčela 90% kritiků.

[Josef Kufner]

Navrhuju to přejmenovat na systemd-netd.

[pavlix]

To by se pletlo se systemd-networkd a takové prasárny dělá snad jenom Microsoft (Office Open XML versus OpenDocument used in OpenOffice).

[Josef Kufner]

Ale o to větší sranda by to mohla být.

[pavlix]

Já osobně jsem to navrhoval přejmenovat na networkd dříve než na to přijdou soudruzi ze systemd, a jsem si jistý, že jsem na to ani nepřišel sám, ale nikdo mě neposlouchal a teď už je pozdě.

[Josef Kufner]

A co je prohodit?

[Bedňa]

Kompilácia na Ubuntu14.04

Inštalácia potrebných knižníc:

sudo apt-get install intltool libxml-parser-perl libdbus1.0-cil-dev libdbus-glib-1-dev libgudev-1.0-dev libnl-3-dev libnl-route-3-dev libnl-genl-3-dev uuid-dev libncurses5-dev libtinfo-dev libreadline-dev libnss3-dev libnspr4-dev ppp-dev

Stiahnutie balíčkov libndp0 libndp-dev

Stiahnutie zdrojákov tu.

Odstránenie NM: apt-get remove network-manager-gnome network-manager network-manager-pptp

Kompilácia:

./configure
make
sudo make install

Štart sudo start network-manager

No a ono to chodí Škoda nemám tu nainštalovanú žiadnu virtuálku že by som niečo otestoval.

Pokiaľ sú nejaké otázky čo tu môžem odskúšať sem s nimi.

Na nmtui je asi nejaká voľba v configu, páč ten sa mi neskompiloval, ale videl som obrázky v blogu vyzerá to dobre.

Čo sa týka kódu, tak bude asi fakt prečistený, páč žiadny warning.

[Pavel Bařina]

Mohu se zeptat jak je na tom podpora l2tp over IPsec? Používá to někdo? Potřebuji občas takhle přistupovat na jeden router Zywall od Zyxelu. Nikdy mi to nejelo a naopak router pak zatuhnul. Bohužel nejsem tak zdatný a hlavně nemám čas to řešit.

[Bedňa]

Ak máš náhodou Ubuntu, tu máš návod.

[Pavel Bařina]

Ano o tomhle prográmku vím a na Ubuntu a Debianu to funguje. Nicméně an archu to nejelo a Fedora nebo CentOS taky ne.

[pavlix]

Můžeš být první, kdo to portuje ;).

[drunkezz]

lol pavlix...tu je to samy devel clovek co?:)..toto pobavilo

D.

[pavlix]

Psaní specfiles není žádný development, navíc když napíše těm správným lidem (maintainerům dalších podobných pluginů), tak mu ochotně pomůžou. Já nevím proč všichni předpokládají, že v open source všechno udělá někdo za ně a oni už budou jenom konzumovat.

[drunkezz]

lebo je to tak...normalne?......1% vyvyja 100% uziva 5% reportuje....iste snazis sa tu navadzat ludi na aktivnejsi pristup pri testovani a pouzivani za co ti patri klobuk hore, ale tvoje "Ja nevim" v poslednej vete skutocne povazujem za naivne. tiez si nevyrabas auto ani nereportujes jeho bugy ale uzivas...tak ako milion dalsich veci....

D.

[pavlix]

Mně přijde daleko naivnější, když se lidi degradují na úroveň hospodářských zvířat a čekají, co jim kdo strčí pod nos a podle toho jsou buď šťastní nebo jdou do diskuze nadávat těm, kteří v dané oblasti dělají aspoň něco.

tiez si nevyrabas auto ani nereportujes jeho bugy ale uzivas...

Když už použiješ přirovnání s auty, tak si to přirovnání aspoň promysli. Pokud bych namísto zajištění opravy auta šel jenom nadávat na ábíčko, jak je volkwagen na hovno, tak bych už dávno dojezdil. Nehledě na to, že plácáním v diskuzích bych si to auto ani nepořídil. Tak co, zkusíme vymyslet nějaké blbější přirovnání?

[drunkezz]

prva veta je z mojho pohladu vyplod hnevu...nic s tym neurobim (kazdopadne ze ludia chodia na abclinuxu.cz kde maju mozno asncu ze im niekto mudrejsi skusenejsi - proste nie hospodarske zviera poradi- je im z mojho pohladu ku cti nie opacne)

 

v pripade toho porovnania s autom: princip to vystihuje, ziavne ho nechces najst medzi riadkami, moja chyba. anyway stojim si za to ze tvoja arogantna implikacia ze sa ludia degraduju na uroven hospodarskych zvierat, len kvoli tomu ze nie su schopni/ochotni aktivne prisievat k vyvoju je primitivna.  Ja tu nevidim ani nadavanie vyvojarom ani nic podobne. Tak ja ako aj ini napisali svoju zlu skusenost so softwarom a povedzme specializovanom serveri. presne ako ty napises na auto.cz ze ten tvoj vw netaha uplne najlepsie, a mozno potom zajdes do servisu, alebo sa napriek frflaniu uspokojis, ze to proste netaha.....alebo...ten motor prote rozoberie a spravis si to sam, alebo ho vytunis. Peklo na vsetkych ktory nemaju na serivs, alebo to nevedia opravit, a len frfu na autofore kde im mozno poradia...

D.

[Bedňa]

To prirovnanie je fakt mimo, nechcem sa hádať, ale možno sa mi to podarí vysvetliť

Máš softvér ktorí má nejakú funkcionalitu. Pokiaľ ide o uzatvorený softvér, tak si o doplnenie funkcionality musíš zažiadať a tá ti za nejaký obnos bude doplnená.

Alebo ide o slobodný softvér, v tom prípade máš niekoľko možností. Prvá požiadať o čo chceš a za prachy ti to tam autor dopíše. Druhá možnosť je autora presvedčiť aby sa problému začal venovať, aspoň hlásením bugreportov. Tretia možnosť, zober si zdrojáky a dopíš si to sám.

[pavlix]

Alebo ide o slobodný softvér, v tom prípade máš niekoľko možností. Prvá požiadať o čo chceš a za prachy ti to tam autor dopíše. Druhá možnosť je autora presvedčiť aby sa problému začal venovať, aspoň hlásením bugreportov. Tretia možnosť, zober si zdrojáky a dopíš si to sám.

Čtvrtá možnost je vyjádřit se na Abclinuxu, že jsou autoři v lepším případě idioti, v horším případě podlé svině.

[Bedňa]

Zas je druhá vec, čo si my môžeme myslieť o nich. Myslím že o tom nemúsime na Abičku ani písať :)

[drunkezz]

mne stale nie je v nasej diskusii jasne kde sa zobralo to rozdelenie na A, ludi co pred tym ako pridu na abclinuxu napisat o svojom probleme, postnu bugreport B, ti ktori nadavaju na vsetkych ze su idioti ci v horsom pripade podle svine.....to fakt medzi tym nic nie je? (to je cele co chcem povedat)

D.

[pavlix]

Tak šedá zóna vždy existuje, ale to jsem tak nějak považoval za samozřejmé.

[pavlix]

prva veta je z mojho pohladu vyplod hnevu...

Přitom v ní není hněvu ani kousek.

princip to vystihuje

Nikoliv. Ale to už jsem popsal a není důvod se opakovat.

tvoja arogantna implikacia ze sa ludia degraduju na uroven hospodarskych zvierat, len kvoli tomu ze nie su schopni/ochotni aktivne prisievat k vyvoju je primitivna

To je tvůj názor a máš na něj samozřejmě právo. Nicméně už použití slova schopni je podle mě falešnou argumentací. Já přeci neříkám, že by se měli aktivně účastnit lidé, kteří toho nejsou schopni (třeba z důvodu nějakého zásadního postižení) ale věřím tomu, že takových je v diskuzích naprosté minimum.

Ale dosavadní život mě naučil bránit se vyžírkům, kteří (údajnou) absenci schopností proměňují ve výhodu a na jejím základě buď kopou do těch, kteří něco dělají, nebo od nich vyžadují pomoc a místo poděkování a pokusu se nějak revančovat jenom nadávají. Zároveň se snažím pomáhat těm, kteří se zatím ještě bránit nenaučili.

[pavlix]

A vůbec nevím, proč píšu tak dlouhé komentáře, když to jde napsat prostým:

Kdo nic nedělá, nic nezkazí.

[ukarr]

Z toho plyne, že určití lidé by raději neměli nic dělat.

[pavlix]

A kteří to jsou?

[ukarr]

Přece ti, co zkazí všechno, na co sáhnou.

[odin]

Na jednom stroji se mi nm chova divne. Nahodne se odpojuje od wifi a applet dokonce donekonecna otravuje se zadanim hesla i kdyz to, ktere si pamatuje, je spravne. Vyresil jsem to odinstalovanim nm a vlastnim skriptem pro pripojeni... Inu je videt, kam dosel GNU/Linuxovy desktop v 21. stoleti Na jinych strojich nm vicemene funguje normalne, ale stejne jej radeji odinstalovavam. Je lepsi mit to trochu ve vlastnich rukou, kdyz clovek vi, co kraviny ten program zvladne udelat.

[little.owl]

To kote na konci blogu je asi na uklidneni horkych hlav ... Marketing pres kotata, stenata ci deti asi funguje vsude - asi narvu nejake kote do project planu noveho projektu, protoze nic jineho to nezachrani.

[Jirka]

Komentáře jsem četl jen zběžně, takže nevím, jestli se neopakuji, ale děkuji pavlix(ovi) za vše jeho úsilí v tomto směru.

[pavlix]

Díky. Snad jen dodám, že ač do tohoto vydání šlo netriviální množství mojí práce, samotné vydání už jsem sledoval jen zběžně a pohlídal si vyřešení tří starších minor bugů, a že touto verzí úsilí nekončí a očekávám spoustu drobných problémů, které se budou muset řešit.

[little.owl]

+1

[Bedňa]

+1

[Marián Kyral]

Koukám, že se to tady pěkně rozjelo. Osobně NM nepoužívám, střídám jen pár míst a ty mám nakonfigurované ve wpa_suplicantu. Potud OK. Jediné, co mne trápí je nastavení proxy. Doma to je bez proxy, v práci je jedna proxy, u zákazníka jiná proxy. Zatím to mám tak, že při startu systému skript podle IP zjistí, kde právě jsem a podle toho se nastaví http_proxy a https_proxy proměnné prostředí. Problém je, že tyto proměnné se načítají jen při startu a pozdější změna už pak nemá efekt. Takže nemůžu NB v práci uspat a doma jej probudit. Zůstane tam firemní proxy a musím se odhlásit a znova přihlásit aby se změna projevila.

Hodila by se nějaká možnost, jak informovat aplikace, že se proxy nastavení změnilo. Ale to asi bude problém v jednotlivých aplikacích. I když by to asi chtělo nejprve definovat nějaký systém notifikací. A nebo už něco takového existuje, jen o tom nevím?

[pavlix]

Proxy je věčným tématem, které do NetworkManageru nosí lidé z Gnome. Bohužel pro ty, co by to chtěli využívat, je toto téma věčně ve stejném počátečním stavu.

[Marián Kyral]

No možná bych se mohl inspirovat tady: proxydriver. Jen se obávám, že třeba na Psi+ to fungovat nebude. Ale uvidím až to vyzkouším.

[Samuel]

Používam taký malý workaround - nainštalovať si proxy na localhost (squid, tinyproxy, ...), ktorá bude všetko preposielať na externú proxy a aplikácie nasmerovať na localhost. Potom stačí zmeniť konfirugáciu a reštart tejto lokálnej proxy.

[Josef Kufner]

Toto jsem jeden čas používal také. Ale lokální proxy přidává na latenci a u rychlého připojení na stránkách s desítkami kousků bordelu to je celkem znát.

Druhou možností je lokální transparentní proxy a přehazovat to v iptables. Ale než jsem se k tomuto dostal, vyšly tu proxy z módy.

[Josef Kufner]

Příloha:

• set-proxy (1398 bytů)

Btw, používal jsem tento script – viz příloha. Umí to obsluhovat tinyproxy, privoxy, nebo ffproxy, podle toho, co je zrovna nainstalováno.

[Marián Kyral]

Díky, lokální proxy mne taky napadla, ale nechci žádný další démon žeroucí cpu a paměť.

Ideální by bylo, kdyby se všechny programy komunikující přes http někam zaregistrovaly a v případě, že dojde ke změně proxy, tak dostanou okamžitě info a můžou se podle toho zařídit.

Zatím jsem to vyřešil tím skriptem při startu a vždy když se přesouvám, tak NB vypínám.

[Spike]

Jo tohle celkem pěkně funguje na Mac OS X, tam vesměs aplikace systémové nastavení proxy respektují.

[s0]

vypíchnul bych slova: celkem a vesměs. Teď s tím aktuálně bojuju.

[Spike]

Beru, Mac OS X už pár releasů nepoužívám.