Portál AbcLinuxu, 30. dubna 2025 15:24
Ale fungují bez něj jiní, tak si snad také zvyknu. Jinak RPM z DEBka jde udělat alienem, ale to jsem nezkoušel, z podobných pokusů jsem vyléčen od chvíle, co jsem se pokoušel některé Fedoři RPMko naroubovat do openSUSE - díky závislostem jsem stahoval a hledal asi hodinu balíčky a pak jsem zjistil, že to prostě nepůjde díky odlišné verzi některé knihovny :-/
Díky, zkusím
27.3.2012 18:46
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
27.3.2012 22:42
Dreit | skóre: 15
| blog: Dreit a jeho dračí postřehy
| Královehradecký kraj
Koukám že nejsem sám 
29.3.2012 07:56
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
29.3.2012 16:01
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
Note Although the aptitude command comes with rich features such as its enhanced package resolver, this complexity has caused (or may still causes) some regressions such as Bug #411123, Bug #514930, and Bug #570377. In case of doubt, please use the apt-get and apt-cache commands over the aptitude command.Ja osobne som to našiel niekde v poznámkach v Debiane, pred asi štyrmi rokmi. Neviem či to nebolo priamo dopísané v helpe k Aptitude :)
29.3.2012 18:03
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
29.3.2012 18:10
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
29.3.2012 09:55
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
Tak mi najdi něco jiného, co má schopnosti svaté krávy.Kalousek?
Mě třeba ta minimalističnost instalace vyhovuje. Prostě rychle nainstalovat základ z cd, rozjet síť, openssh a zbytek se dá dodělat později z pohodlí domova.
Rozdělovač disku je taky imho v pohodě. Lze s ním provádět LVM na dm-raidem, a větší vymoženost co by byla potřeba mě nenapadá.
27.3.2012 15:37
Dreit | skóre: 15
| blog: Dreit a jeho dračí postřehy
| Královehradecký kraj
Když vybereš "expertní instalaci" (v pokročilých volbách), tak ti nabídne jestli chceš rovnou přidat contrib a non-free
27.3.2012 22:45
Dreit | skóre: 15
| blog: Dreit a jeho dračí postřehy
| Královehradecký kraj
Já taky, i když potom si to dloooooooouhym seznamem "nezbytných" balíků zase rychle zase*u
1) Copak je tam špatně, že je třeba používat volbu -f?
27.3.2012 21:07
28.3.2012 08:29
27.3.2012 15:54
28.3.2012 09:00
28.3.2012 10:39
29.3.2012 16:11
27.3.2012 14:37
27.3.2012 15:52
27.3.2012 14:42
27.3.2012 16:38
27.3.2012 17:36
apt-get install XXX, na což mi apt odpověděl, že balíček XXX vyžaduje balíky YYY a ZZZ, které se nebudou instalovat. Pro vyřešení problému zadejte apt-get -f install. No a když jsem to zadal, tak se dané balíky stejně nainstalovaly V danou chvíli mi přišlo, že jde o to, že daný balík závisí na knihovnách z non-free, ale vzhledem k tomu, že se mi to nedaří zopakovat, tak netuším :-/
Jinak kdybys měl zájem na vývoji spolupracovat, nějaký balič do RPM by se určitě šiknul. Každopádně díky za nabídku!
28.3.2012 07:12
Marián Kyral | skóre: 29
| blog: Sem_Tam
| Frýdek-Místek
/etc/network/interfaces (dohromady) v openSUSE v /etc/sysconfig/network/ (souborech pro každý interface zvlášť) a v CentOS v /etc/sysconfig/network-scripts (zvlášť). Proč to mám znovu hledat, kde ta která konfigurace je zrovna v této distribuci.
/etc/NetworkManager/system-connections/ je (nebo by mělo být) všude stejné ...
Jednak Network Manager používám tak maximálně na notebooku, ale ne na serverech a ani ne na stacionárních pracovních stanicích, které mají fixní interface.Tak pokud žádáš sjednocení, tak bys měl doufat, že časem budeš pohodlně používat NM všude :).
Za druhé tohle byl jen jeden příklad, který mne napadl, protože jsem se s ním potkal v minulém měsíci. Těch příkladů v rozdílném umístění konfigurace je mnohem více.Jen bych tě rád upozornil, že tohle záleží na tvůrcích distribucí. Každá z distribucí může přijít s nějakou inovací, změnou. Každá jiná distribuce může danou změnu přijmout či odmítnout. Některé věci budou v konkrétních distribucích odlišné už z principu (třeba Gentoo nebude mít stejnou konfiguraci systému pro správu instalovaného software jako Fedora). U těch, které můžou být společné, se naráží na problémy jak v kvalitě inovací, tak v úsudku těch, kdo je mají přijmout „jinde“. Třeba NetworkManager byl do několika distribucí přijat ve stavu, kdy byl vyloženě desktop-only. Až se začnou rozšiřovat IPv6-only sítě, bude zase všechno jinak :). Já zase nevím, co bys ve světě distribucí čekal? Kdyby byly všechny stejné, tak se z nich dá udělat jedna a měnit jenom logo :D.
Tak pokud žádáš sjednocení, tak bys měl doufat, že časem budeš pohodlně používat NM všude :).Taková představa o budoucnosti mi přijde naprosto děsivá :) Pochybnější kus softwaru než NM aby jeden pohledal... Po pravdě řečeno, nejlepší způsob konfigurace sítě je stejně jednoduchý skript, který párkrát zavolá
ip a spol. Je to perfektně přehledné a pokud potřebuji cokoliv méně obvyklého (třeba policy-based routing), mohu to do toho skriptu triviálně připsat.
Taková představa o budoucnosti mi přijde naprosto děsivá :)To tě naprosto chápu :).
Pochybnější kus softwaru než NM aby jeden pohledal...Asi bych se měl rovnou přiznat, že se účastním výběrovky právě na vývoj NetworkManageru. A nezávisle na tom už mám v merku i nějaké ty návrhové chyby.
Po pravdě řečeno, nejlepší způsob konfigurace sítě je stejně jednoduchý skript, který párkrát zavolá ip a spol.Máš naprostou pravdu. Dělám to tak, kdykoli distribuční nástroj nezvládá. A jediný nástroj, u kterého se mi to nestává, jsou interfaces v Debianu, kde se dají příkazy vepisovat přímo do konfigurace. Jako kernelář a síťař podle mě ani nemůžeš mít NetworkManager rád, protože to dělá příliš mnoho věcí samo. Ale rád bych se tě zeptal na návrh řešení následujícího zadání: Chci uzpůsobit (jakoukoli) distribuci instalovanou na notebook či jiné mobilní zařízení tak, aby šel drátově či bezdrátově připojit do libovolné sítě s nějakou automatickou konfigurací. Ty sítě můžou mít automatickou konfiguraci řešenou různě. Testovací schémata jsou následující (všechny z praxe): 1) IPv4 adresy, gateway a IPv4 DNS z DHCP 2) IPv4 adresy, gateway a IPv4 DNS z DHCP, IPv6 adresy a gateway z RA 3) IPv6 adresy, gateway a IPv6 DNS z RA 4) IPv6 adresy a gateway z RA, IPv6 DNS z DHCPv6 5) IPv6 adresy a IPv6 DNS z DHCPv6, IPv6 gateway z RA Komlikovanější schémata zatím nechme stranou, ale přidejme ještě jeden požadavek, a to aby ten systém uměl sdělit uživateli a aplikacím, jestli je připojení k síti a plně zkonfigurovaný nebo ne. Samotný dhclient momentálně zvládá pouze 1 a 2 (s tím, že IPv6 pro 2 zajišťuje trochu netypicky jádro). NetworkManager momentálně z DNS konfiguruje jenom RDNSS, ale DNSSL půjde celkem jednoduše přidat. Pak má NM ještě problémy s timeouty u RDNSS, ale to je částečně i kvůli blbě napsanému RFC, když nepočítám regresi v poslední verzi ve F17, kde už to nefunguje vůbec. Já osobně zatím vidím nejjednodušší řešení v opravě NetworkManageru nebo v napsání software, který bude mít podobnou architekturu jako NM a tudíž se ti nebude líbit. Obchází se tím i komplikace, kdy v linuxovém jaderném světě se DNS de facto nepovažuje za součást síťové konfigurace, zatímco uživatel je obvykle bez DNS dost v háji. Nad tím se blbě staví tenká architektura, kde se o každou síťovou věc stará jiný démon a celé to zastřešuje pouze kernel.
A jediný nástroj, u kterého se mi to nestává, jsou interfaces v Debianu, kde se dají příkazy vepisovat přímo do konfigurace.Ty jsou z těch lepších, ale selžou například v okamžiku, kdy chci na ethernetu používat více VLANů přes 802.1q.
Přijde mi, že nejzásadnější návrhová chyba Network Manageru je ta, že je to nástroj o několik řádů komplikovanější, než problém, který se snaží řešit. Zdrojáky verze 0.8.1 mají přes 65000 řádků, ačkoliv celý program v podstatě nic složitého nedělá.Nemůžu posoudit, zatím jsem se díval pouze do zdrojových kódů částí okolo IPv6 a ty byly celkem přehledné a dělaly víceméně co bylo potřeba. Takže mě čeká nějaké ošklivé překvapení, že?
Ještě donedávna se ani nebyl schopen vyrovnat s prostým faktem, že jeden počítač může používat více uživatelů, a myslím, že dodnes se pořádně neumí vyrovnat s případem, kdy je jeden počítač připojen k síti dvěma rozhraními (typicky WiFi + ethernet).O tom se teďka docela hodně mluví.
Souhlasím s Tebou, že nějaký daemonek na automatickou konfiguraci sítě se hodí, ale měl by být především navržen tak, aby byl velmi jednoduchý, uměl fungovat i na holém systému bez všelijakých DBUSůTak zrovna D-bus mi připadá jako celkem rozumný požadavek. Ale jak říkám, chápu tvé výtky.
Ty jsou z těch lepších, ale selžou například v okamžiku, kdy chci na ethernetu používat více VLANů přes 802.1q.Tak na to mi naopak debianí interfaces vyhovovaly perfektně.
Takže mě čeká nějaké ošklivé překvapení, že?Tipl bych si, že ještě nejedno :) Ale držím palce.
Tak na to mi naopak debianí interfaces vyhovovaly perfektně.No jo, ale to mně nutí ke konkrétnímu způsobu pojmenování interfaců – daleko přehlednější mi přijde pojmenovávat VLANky podle toho, k čemu se používají, namísto čísel. Navíc je to použitelné jen tehdy, když se o VLANky stará driver 8021q. Jakmile je spravuje přímo síťová karta (což je běžné u různých integrovaných ethetnetových switchů), už to popsat nejde.
Tipl bych si, že ještě nejedno :) Ale držím palce.Děkuju ti.
No jo, ale to mně nutí ke konkrétnímu způsobu pojmenování interfaců – daleko přehlednější mi přijde pojmenovávat VLANky podle toho, k čemu se používají, namísto čísel.A zkoušel jsi to? :).
Navíc je to použitelné jen tehdy, když se o VLANky stará driver 8021q. Jakmile je spravuje přímo síťová karta (což je běžné u různých integrovaných ethetnetových switchů), už to popsat nejde.Popravdě s tímhle mají problémy i v konfiguraci OpenWRT, které je na routery specializované. Switche se zpravidla konfigurují trochu jinak než VLANy na klasických kartách. Jestli to je zavedeno do debian interfaces, to nevím, ale pokud na tom někomu záleží, jistě není problém to doplnit stejně jako jsou doplněné VLANy na eth rozhraních.
A zkoušel jsi to? :).Nezkoušel, ale nevím, kde by v případě jména, které neobsahuje číslo VLANky, ten konfigurátor číslo VLANky našel. (Možná na to nějaký atribut existuje, ale jak se jmenuje? Dokumentace je velmi skoupá, manuálová stránka možnost konfigurovat VLANky vůbec nezmiňuje.) Mimochodem, jde debianími interfaces popsat rozhraní s více IP adresami?
Popravdě s tímhle mají problémy i v konfiguraci OpenWRT, které je na routery specializované. Switche se zpravidla konfigurují trochu jinak než VLANy na klasických kartách. Jestli to je zavedeno do debian interfaces, to nevím, ale pokud na tom někomu záleží, jistě není problém to doplnit stejně jako jsou doplněné VLANy na eth rozhraních.Ale jistě, doplnit jde ledacos. Ale dává smysl, aby každou pro každou z desítek featur síťového subsystému musel existovat zvláštní hack v konfigurátoru interfaců? Já na svých strojích konverguji k tomu, že konfigurace sítě je shellový skript, který si na ty operace, které nejsou úplně triviální, volá předdefinované funkce.
Nezkoušel, ale nevím, kde by v případě jména, které neobsahuje číslo VLANky, ten konfigurátor číslo VLANky našel.Těch direktiv na VLANy je víc než jen vlan_raw_device.
Mimochodem, jde debianími interfaces popsat rozhraní s více IP adresami?Jde. Pomocí aliasů. A není to jediný nedostatek interfaces, například mi vadí, že se délka prefixu IPv4 musí zadávat po staru maskou, že délka prefixu nejde prostě připsat k adrese CIDR notací. Našlo by se toho víc. Ale při troše snahy to použít jde.
Ale jistě, doplnit jde ledacos. Ale dává smysl, aby každou pro každou z desítek featur síťového subsystému musel existovat zvláštní hack v konfigurátoru interfaců?Tak, pokud nechceš používat všude přímo příkazy, což samozřejmě v interfaces můžeš, v tom ti nikdo nebrání, ale poskytuje to určité nepohodlí v tom, že musíš psát i zrušení té stejné konfigurace. Prostě typické důsledky rozdílu mezi deklarativním a imperativním konfiguračním jazykem.
Já na svých strojích konverguji k tomu, že konfigurace sítě je shellový skript, který si na ty operace, které nejsou úplně triviální, volá předdefinované funkce.Chápu. Ale budeš jeden z mála :). Já to naposledy takhle dělal před mnoha lety v nějakém SUSE, kde nešlo do konfigurace pořádně napsat bridge.
Těch direktiv na VLANy je víc než jen vlan_raw_device.Kde je najdu? Manpage mlčí.
Jde. Pomocí aliasů.Argh, já nechci obskurní virtuální interfacy určené pro kompatibilitu s preglaciální érou. Já chci jeden interface s několika adresami :) To je vůbec druhá věc, která mi na debianím
ifupu vadí: ještě stále používá naprosto obsoletní kernelové rozhraní, takže většina nových kernelových featur buďto není k dispozici, nebo se musí popisovat obskurně.
Tak, pokud nechceš používat všude přímo příkazy, což samozřejmě v interfaces můžeš, v tom ti nikdo nebrání, ale poskytuje to určité nepohodlí v tom, že musíš psát i zrušení té stejné konfigurace. Prostě typické důsledky rozdílu mezi deklarativním a imperativním konfiguračním jazykem.Lze nicméně nalézt kompromis mezi deklarativností a imperativností: Jednou (imperativně) popíši, jak se zakládá a maže VLAN, a pak to vícekrát (deklarativně) použiji u jednotlivých rozhraní. Přesně tohle od systému na konfiguraci sítě čekám: vlastnosti rozhraní by neměly být zadrátované do programu, každou z nich bych si měl mít možnost nadefinovat.
Kde je najdu? Manpage mlčí.Chyba je samozřejmě na mé straně, špatně jsem si to pamatoval, nejspíš kvůli záměně s bridgováním. Ale, díky tobě jsem si všiml, že se vlany dají nastavovat přes ip. Dosud jsem měl za to, že se nastavují pouze přes vconfig, a ten zřejmě neumí vše to, co ip.
Argh, já nechci obskurní virtuální interfacy určené pro kompatibilitu s preglaciální érou. Já chci jeden interface s několika adresami :)Můžeš následně příkazem ip ověřit, co ve skutečnosti vzniklo :).
To je vůbec druhá věc, která mi na debianím ifupu vadí: ještě stále používá naprosto obsoletní kernelové rozhraní, takže většina nových kernelových featur buďto není k dispozici, nebo se musí popisovat obskurně.Jo. Debianí konfigurace je sto let za opicema. Prostě není s čím tak úplně srovnávat.
Lze nicméně nalézt kompromis mezi deklarativností a imperativností: Jednou (imperativně) popíši, jak se zakládá a maže VLAN, a pak to vícekrát (deklarativně) použiji u jednotlivých rozhraní.Dá se, ale z globálního pohledu je lepší mít ten popis deklarativního jazyka ustálený a oddělený. Spousta lidí dává mnohem lepší výsledky, když už je to pro ně trochu foolproof.
Přesně tohle od systému na konfiguraci sítě čekám: vlastnosti rozhraní by neměly být zadrátované do programu, každou z nich bych si měl mít možnost nadefinovat.Ta tvá představa mi pořád není úplně jasná.
Ta tvá představa mi pořád není úplně jasná.Představuji si to asi takhle: konfigurační program zná nějakou základní množinu vlastností síťových rozhraní, které umí sám nastavovat, a pak umožňuje definovat vlastnosti nové spolu s pravidly na jejich nastavování. Tedy kupříkladu kdybych chtěl rozhraním přidělovat IPX adresy, nadefinuji nový atribut ipx-address a k němu dva příkazy: jeden, který se má vykonat při nahazování interfacu, druhý při shazování. A pak už budu k jednotlivým rozhraním jen připisovat nový atribut a vše bude fungovat.
Dá se, ale z globálního pohledu je lepší mít ten popis deklarativního jazyka ustálený a oddělený.To je dobrý důvod k tomu, aby jazyk nabízel bohatou standardní knihovnu vlastností, nikoliv aby nešlo nové dodefinovat.
Tedy kupříkladu kdybych chtěl rozhraním přidělovat IPX adresy, nadefinuji nový atribut ipx-address a k němu dva příkazy: jeden, který se má vykonat při nahazování interfacu, druhý při shazování. A pak už budu k jednotlivým rozhraním jen připisovat nový atribut a vše bude fungovat.Jo, to zní docela rozumně. Jako příjemný bonus. Ale mě teďka daleko víc zajímá zpracování automatické konfigurace Wifi, IPv4 a IPv6, což je věc, která mi jako celek nefunguje správně nikde. Ani s NetworkManagerem, ani s jiným démonem.
To je dobrý důvod k tomu, aby jazyk nabízel bohatou standardní knihovnu vlastností, nikoliv aby nešlo nové dodefinovat.To jo. Omezení množiny vlastností může mít jiné výhody, které ale člověk hned nedocení, když se na systém dívá z pohledu, kdy programátor, administrátor i uživatel jsou jedna osoba.
To jo. Omezení množiny vlastností může mít jiné výhody,Jaké vlastně?
Jaké vlastně?Omezená množina nastavení umožňuje postavit dobré klikátko, webovou administraci a třeba i CLI jehož model odpovídá těm předchozím. To vše s mnohem menším prostorem pro chyby. Podle mě nic, co by zrovna tobě vyhovovalo :). V podstatě se jedná o abstrakci, která ti třeba umožňuje sjednotit pohled na několik různých věcí. Zkus si třeba představit, že by každý druhý člověk měl na základě ústně předaných informací o IP adrese, bráně apod sestavit skript, který zajistí konfiguraci systému pro danou síť. Tak to nefunguje. Za to když omezíš celou konfiguraci na pár políček, ve kterých se nastaví dané hodnoty, tak je to ok. Můžeš namítnout, že v backendu není potřeba nic omezovat a že klikátko zobrazí jen podmnožinu konfigurace. Pak se ale dostaneš do situace, kdy změna expertním nástrojem bude často nedetekovatelné pohledem do toho GUI nástroje. Tudíž přestanou fungovat všechny standardní návody kromě těch, které začínají vyresetováním celé konfigurace (či reinstalací).
Tak to nefunguje. Za to když omezíš celou konfiguraci na pár políček, ve kterých se nastaví dané hodnoty, tak je to ok.To, že je to OK, je pouze iluze. Dnešní svět sítí zkrátka je složitý a dříve či později potkáš situaci, kterou nástrojem se třemi nastavitelnými parametry vyřešit nejde. Myslím si, že je zásadní chyba chtít v takovém případě po uživatelích, aby nástroj zahodili a síť si najednou začali konfigurovat úplně jinak. Daleko lepší je, když jim spřátelený počítačový kouzelník poradí, aby na nějaké místo připsali magické zaříkávadlo. Zbytku konfigurace pak stále budou rozumět a když se přestěhují do jiné sítě, zaříkávadlo budou zase umět vypnout. Obecně: přijde mi velmi důležité, aby se nástroje chovaly spojitě. Tedy aby se pomocí nich daly jednoduché problémy vyřešit jednoduše a ty složité o něco složitěji. Nikoliv aby v triviálním případě šlo nástroj používat triviálně a v jakémkoliv jiném to nešlo vůbec. Skálopevné přesvědčení programátorů o tom, že vědí, co přesně uživatelé budou potřebovat, je příznakem naprosté naivity. Skutečnost je taková, že ani programátoři, ani uživatelé nevědí, co je čeká zítra. Takže dobrý program musí počítat s nečekaným a být dost flexibilní na to, aby se ono nečekané dalo zvládnout, byť třeba ne pohodlně. Ušít nástroj na míru největšímu ignorantovi z okolí a nestarat se o pokročilejší uživatele, je zkrátka cesta do pekel. Smutné je, že Gnome se po této cestě vydal.
Můžeš namítnout, že v backendu není potřeba nic omezovat a že klikátko zobrazí jen podmnožinu konfigurace.To samozřejmě namítnu, protože stačí nad návrhem klikátka trochu přemýšlet a vybavit ho textovým polem, ve kterém se taková nastavení objeví. I uživatel, který jim nebude rozumět, bude vědět, že tam jsou, a bude je moci smazat.
Dnešní svět sítí zkrátka je složitý a dříve či později potkáš situaci, kterou nástrojem se třemi nastavitelnými parametry vyřešit nejde. Myslím si, že je zásadní chyba chtít v takovém případě po uživatelích, aby nástroj zahodili a síť si najednou začali konfigurovat úplně jinak.V tomhle se neshodnem. Pokud nelze udělat nástroj, který plně vyhovuje jak běžnému síťování, tak tomu advanced (a v tomhle případě se tím myslí hodně advanced, protože do té základní konfigurace lze schovat docela hodně věcí, které kdekdo považuje za nadstandard), tak může být vhodnější použít nástroje dva. Byť by ten druhý byl právě shell skript s voláním příkazu ip.
Daleko lepší je, když jim spřátelený počítačový kouzelník poradí, aby na nějaké místo připsali magické zaříkávadlo. Zbytku konfigurace pak stále budou rozumět a když se přestěhují do jiné sítě, zaříkávadlo budou zase umět vypnout.Vycházíš z toho, že se nemalé procento lidí setká ze situací, která nejde vyřešit základními nástroji. Já s tímhle předpokladem nesouhlasím a dokonce si myslím, že NetworkManager (nebo kterýkoli nástroj, který by ho měl nahradit), dokáže (z hlediska koncepce) pokrýt potřeby začátečníků, pokročilých i lidí jako jsme my. To vše za předpokladu, že se jedná o stroj, který chceme připojit k síti nebo více sítím, tedy koncový bod, ne router. Jestliže NM dokáže poskytnout do určité míry routerovou konfiguraci, je to podle mě trochu omyl, spíš úlitba pro případ, kdy chce začátečník zřídit Wifi AP apod. Na skutečný router v tuhle chvíli NM není vhodný a neumím si zatím představit, že by někdy byl. I když to co mají v OpenWRT je svým způsobem trochu podobné a funguje to jakž takž ke spokojenosti.
Obecně: přijde mi velmi důležité, aby se nástroje chovaly spojitě. Tedy aby se pomocí nich daly jednoduché problémy vyřešit jednoduše a ty složité o něco složitěji. Nikoliv aby v triviálním případě šlo nástroj používat triviálně a v jakémkoliv jiném to nešlo vůbec.Obecně je to dobrý nápad, pro tento konkrétní případ ale nevidím uspokojivé řešení.
Skutečnost je taková, že ani programátoři, ani uživatelé nevědí, co je čeká zítra. Takže dobrý program musí počítat s nečekaným a být dost flexibilní na to, aby se ono nečekané dalo zvládnout, byť třeba ne pohodlně.Svět počítačových sítí je docela dost pasivní a to, co se v něm vytváří nového se zdaleka nemusí druhý den začít používat. Mnohem důležitější mi přijde, aby nástroj typu NM nepřekážel tomu, když si chci s nějakým rozhraním naložit po svém, což lze. Ono stačí se podívat na IPv6, jakou za sebou má historii :).
Ušít nástroj na míru největšímu ignorantovi z okolí a nestarat se o pokročilejší uživatele, je zkrátka cesta do pekel. Smutné je, že Gnome se po této cestě vydal.No počkej, to bych si mohl vzít jako spokojený uživatel Gnome a skoro spokojený uživatel NetworkManageru osobně. Jenže já jsem k tomu přišel trochu z jiné strany než ty. Já jsem vzal nějakou verzi Fedory a začal jsem ji úmyslně používat „tak jak je“, tedy včetně výběru základních programů jako Evolution, a včetně výběru výchozího prostředí, tedy Gnome 3, a postupně jsem se téměř smířil s tím NetworkManagerem.
To samozřejmě namítnu, protože stačí nad návrhem klikátka trochu přemýšlet a vybavit ho textovým polem, ve kterém se taková nastavení objeví. I uživatel, který jim nebude rozumět, bude vědět, že tam jsou, a bude je moci smazat.Jo, to je pravda, stačí vytvořit nějaký about:config jako ve Firefoxu apod. V podstatě jediný důvod, proč tomu tak u NM není je to, že se hřeší na textovou konfigurační databázi, kde každé rozhrané má textovou konfiguraci ve formě název-hodnota. Alespoň tedy pokud se používá rhplugin, s vestavěnou konfigurací jsem NM ještě nepoužíval. Takže ano, v tuhle chvíli se dají konfigurovat i hodnoty, které v GUI nejsou, a je možné rozbít konfiguraci tak, aby to uživatel přes GUI dohromady nedal.
Pokud nelze udělat nástroj, který plně vyhovuje jak běžnému síťování, tak tomu advanced (a v tomhle případě se tím myslí hodně advanced, protože do té základní konfigurace lze schovat docela hodně věcí, které kdekdo považuje za nadstandard), tak může být vhodnější použít nástroje dva.Ale zajisté. Jenže důkaz toho, že to nejde, zatím nikdo nepřednesl a naopak mám důvodné podezření, že to jde a že to není zase tak těžké.
Vycházíš z toho, že se nemalé procento lidí setká ze situací, která nejde vyřešit základními nástroji.Vycházím a realita mi to potvrzuje – vzhledem k tomu, že takoví lidé často přicházejí pro radu ke mně, vím, že jich není málo. (Typické příklady: WiFi síť, která vyžaduje méně obvyklý mód autentikace. Nebo ethernet s autentikací přes 802.1x.)
Jestliže NM dokáže poskytnout do určité míry routerovou konfiguraci, je to podle mě trochu omyl,Po routerové konfiguraci nevolám. Ale například zmiňovaná možnost připojit se na jednom rozhraní do více VLANek rozhodně není omezena jen na routery.
No počkej, to bych si mohl vzít jako spokojený uživatel Gnome a skoro spokojený uživatel NetworkManageru osobně.I když ušijí software na míru idiotům, rozhodně to neznamená, že nemůže náhodou vyhovovat i někomu jinému
[...] a postupně jsem se téměř smířil s tím NetworkManagerem.To je vskutku rozdíl mezi námi. Já se s věcmi jen tak nesmiřuji, většinou si rozmyslím, čeho přesně chci dosáhnout, a teprve pak hledám nástroje, které mi to umožní. Přeci nebudu celý život používat jenom křížový šroubovák a smiřovat se s tím, že ne všechny šrouby mají křížovou hlavu.
Obecně je to dobrý nápad, pro tento konkrétní případ ale nevidím uspokojivé řešení.Ve svém minulém příspěvku jsem takové řešení navrhl. V čem není uspokojivé?
Ale zajisté. Jenže důkaz toho, že to nejde, zatím nikdo nepřednesl a naopak mám důvodné podezření, že to jde a že to není zase tak těžké.Já nemám víc než osobní zkušenost ohledně toho, co mi v jakém případě vyhovuje.
Vycházím a realita mi to potvrzuje – vzhledem k tomu, že takoví lidé často přicházejí pro radu ke mně, vím, že jich není málo. (Typické příklady: WiFi síť, která vyžaduje méně obvyklý mód autentikace. Nebo ethernet s autentikací přes 802.1x.)Tady bych rozlišoval věci, na které daný nástroj není vhodný koncepčně, a věci, které prostě jen (zatím) neumí.
Po routerové konfiguraci nevolám. Ale například zmiňovaná možnost připojit se na jednom rozhraní do více VLANek rozhodně není omezena jen na routery.Tak tohle bych rozhodně neřadil do kategorie těch, co od začátku koncepčně nevyhovují.
I když ušijí software na míru idiotům, rozhodně to neznamená, že nemůže náhodou vyhovovat i někomu jinémuA já myslel, že to „na míru idiotům“ by mělo jít vyvodit z toho, že „nikdo jiný než idiot to nebude chtít používat“? Pokud bys vzal za vděk předpokladem, že nejsem idiot, tak bych v tomto případě byl protipříkladem :).
To je vskutku rozdíl mezi námi. Já se s věcmi jen tak nesmiřuji, většinou si rozmyslím, čeho přesně chci dosáhnout, a teprve pak hledám nástroje, které mi to umožní.Tímhle způsobem pracuju na většině svých domácích miniprojektů. V první fázi napíšu skript, který provede přesnou akci. V druhé fázi zavedu určitou genericitu, aby byl skript parametrizovatelný. Ve třetí fázi si k tomu udělám interface, který mi vyhovuje. A po celou dobu to můžu používat, ale to ještě neznamená, že ten výsledek či spíše mezivýsledek každému druhému doporučím :).
Přeci nebudu celý život používat jenom křížový šroubovák a smiřovat se s tím, že ne všechny šrouby mají křížovou hlavu.Tak s křížovou hlavou jsem celkem smířený už dlouho, i když občas na speciální účel pokoukávám po hvězdách.
Ve svém minulém příspěvku jsem takové řešení navrhl. V čem není uspokojivé?Podle mě, když do NM přidáme záložku advanced, kde bude k dispozici editovatelný seznam atributů rozhraní, tak to na tvé nespokojenosti nic nezmění.
Tady bych rozlišoval věci, na které daný nástroj není vhodný koncepčně, a věci, které prostě jen (zatím) neumí.Jenže věci, které zatím neumí, vždycky nějaké budou a jádro se vyvíjí daleko rychleji než uživatelské nástroje, takže pokud nástroj nabízí pevnou množinu vlastností bez možnosti rozšíření, není vhodný koncepčně.
Podle mě, když do NM přidáme záložku advanced, kde bude k dispozici editovatelný seznam atributů rozhraní, tak to na tvé nespokojenosti nic nezmění.Pokud tím půjde dostatečně ovlivnit všechno, co NM dělá, tak to mou nespokojenost značně zmenší. Zbytek té nespokojenosti pramení zejména z toho, že NM je obluda, což nepřímo způsobuje, že jeho činnost je velmi těžko debugovatelná. Od programu, který se snaží dělat cokoliv automaticky, bych čekal, že bude umět produkovat velmi detailní log, ze kterého půjde poznat, co se děje. A že i obyčejný uživatel bude mít možnost si tento log vyžádat, aby ho svému čaroději poslal.
Jenže věci, které zatím neumí, vždycky nějaké budou a jádro se vyvíjí daleko rychleji než uživatelské nástroje, takže pokud nástroj nabízí pevnou množinu vlastností bez možnosti rozšíření, není vhodný koncepčně.Otázka ale přece není, jestli nabízí nebo nenabízí rozšíření vlastností, otázka je pouze jak se to rozšíření realizuje.
Pokud tím půjde dostatečně ovlivnit všechno, co NM dělá, tak to mou nespokojenost značně zmenší.Možná tě od května budu otravovat konkrétnějšími otázkami na tvoji představu :).
Zbytek té nespokojenosti pramení zejména z toho, že NM je obluda, což nepřímo způsobuje, že jeho činnost je velmi těžko debugovatelná.Odobludování je strašná práce :).
Od programu, který se snaží dělat cokoliv automaticky, bych čekal, že bude umět produkovat velmi detailní log, ze kterého půjde poznat, co se děje.Já si už nějakou dobu nechávám do /tmp posílat detailní log a řekl bych, že je dost výmluvný.
Otázka ale přece není, jestli nabízí nebo nenabízí rozšíření vlastností, otázka je pouze jak se to rozšíření realizuje.Nutnost rozšíření doprogramovat v Céčku mi moc přijatelná nepřijde
Možná tě od května budu otravovat konkrétnějšími otázkami na tvoji představu :).Rád je uslyším.
Odobludování je strašná práce :).No jo, tak proč tam ty obludy strkali?
Já si už nějakou dobu nechávám do /tmp posílat detailní log a řekl bych, že je dost výmluvný.Teď nemám po ruce žádný stroj s NM, ale jestli mi ukázku logu pošleš, rád si počtu a spravím si názor. Mimochodem, jak si jako obyčejný uživatel takový log pořídím?
Nutnost rozšíření doprogramovat v Céčku mi moc přijatelná nepřijdeJá na to nemám až tak vyhraněný názor.
Rád je uslyším.V to doufám :).
No jo, tak proč tam ty obludy strkali?To naštěstí nebude otázka na mě :). Alespoň zatím.
Teď nemám po ruce žádný stroj s NM, ale jestli mi ukázku logu pošleš, rád si počtu a spravím si názor.https://bugzilla.redhat.com/show_bug.cgi?id=753482 Doporučuju číst od konce.
Mimochodem, jak si jako obyčejný uživatel takový log pořídím?Tak, že administrátor ty logy vůbec zapne. Ale problém je, že jsou docela dost živé, takže třeba já si je radši posílám do /tmp na tmpfs, než na disk. Vyžaduje to trochu víc konfigurace. Pokud máš nějakou radu na tohle, taky si ji rád vyslechnu. Zatím mi syslog celkem vyhovuje. Jistě by to šlo mírně poladit.
Já na to nemám až tak vyhraněný názor.Já v tom vidím jeden obrovský rozdíl: připsat řádek do konfigurace umím poradit po telefonu nebo mailem, připsat 100 řádků Céčka a přeložit už ne
https://bugzilla.redhat.com/show_bug.cgi?id=753482To jsou logy pro někoho, kdo se vyzná ve zdrojácích NM. Rozhodně nic, podle čeho by správce systému mohl pohodlně zjistit, v čem je problém. Hlášky typu "Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled..." toho mnoho neříkají. Kdyby radši zalogoval, co s tím rozhraním přesně dělá.
Tak, že administrátor ty logy vůbec zapne.No právě... Od pohodlného GUI čekám, že když nastane chyba, bude mi samo umět zobrazit detailní informace o tom, co se pokazilo, abych věděl, jestli správným řešením je oeditovat heslo, vytáhnout a zatáhnout kabel, sesílat hromy a blesky na správce místní sítě nebo odinstalovat NM
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.