Byl vydán Mozilla Firefox 127.0. Přehled novinek v poznámkách k vydání, poznámkách k vydání pro firmy a na stránce věnované vývojářům. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 127 je již k dispozici také na Flathubu a Snapcraftu.
Byla vydána (𝕏) nová verze 9.5 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání.
Společnost Raspberry Pi dnes vstoupila na Londýnskou burzu jako Raspberry Pi Holdings plc (investor).
Do 17. června do 19:00 běží na Steamu přehlídka nadcházejících her Festival Steam Next | červen 2024 doplněná demoverzemi, přenosy a dalšími aktivitami. Demoverze lze hrát zdarma.
Apple na své vývojářské konferenci WWDC24 (Worldwide Developers Conference, keynote) představil řadu novinek: svou umělou inteligenci pojmenovanou jednoduše Apple Intelligence, iOS 18, visionOS 2, macOS Sequoia, iPadOS 18, watchOS 11, …
Vyšla nová verze XMPP (Jabber) klienta Gajim, která přidává podporu reakcí pomocí emoji (XEP-0444: Message Reactions) a citace zpráv (XEP-0461: Message Replies). Přehled dalších vylepšení je k dispozici na oficiálních stránkách.
Po po téměř roce vývoje od vydání verze 5.38 byla vydána nová stabilní verze 5.40 programovacího jazyka Perl (Wikipedie). Do vývoje se zapojilo 75 vývojářů. Změněno bylo přibližně 160 tisíc řádků v 1 500 souborech. Přehled novinek a změn v podrobném seznamu.
Uroš Popović popisuje, jak si nastavit Linux na desce jako Raspberry Pi Zero, aby je šlo používat jako USB „flešku“.
Andreas Kling oznámil, že jelikož už se nevěnuje nezávislému operačnímu systému SerenityOS, ale výhradně jeho webovému prohlížeči Ladybird, přičemž vyvíjí primárně na Linuxu, SerenityOS opustí a Ladybird bude nově samostatný projekt (nový web, repozitář na GitHubu).
Po dvou měsících vývoje byla vydána nová verze 0.13.0 programovacího jazyka Zig (GitHub, Wikipedie). Přispělo 73 vývojářů. Přehled novinek v poznámkách k vydání.
Na Fedora.cz vyšel článek NetworkManager 0.9.8. Pavel Šimerda zde představuje nejpodstatnější ze změn, které proběhly od vydání 0.9.4 do vydání 0.9.8, tj. podpora spojování ethernetových rozhraní do virtuálních bridgů, podpora ADSL, zlepšení v oblasti dynamické konfigurace IPv6, opravy týkajících se protokolů DHCPv4 a DHCPv6, příkazové rozhraní a D-Bus API, odstranění distribučně specifického kódu...
Tiskni
Sdílej:
26.2.2013 06:42
backslash | skóre: 1
| blog: backslash
| Spišská Nová Ves
[connection] id=VLAN290 uuid=f834c6d0-d8a0-4356-8d5c-7a2a1c1212b0 type=vlan [vlan] parent=eth0 id=290 [ipv6] method=auto [ipv4] method=manual addresses1=172.17.1.100;24; may-fail=true routes1=224.0.0.0;4;0.0.0.0;0;
Někdo by měl konečně spravit ten vymrdávající se GUI applet, často musim vynutit připojení přes nmcli...Rád tomu někomu popřeju hodně trpělivosti, ať už si vybere kterýkoli z vymrdávajících se GUI appletů.
26.2.2013 11:19
Rezza | skóre: 25
| blog: rezza
| Brno
Ze by z toho Pavlix postupne delal pouzitelny sitovy management pro linux?Společně s dalšími vývojáři a kontributory :).
hodil by se management bondingu a vlan (pokud jeste nema)V konfiguračních souborech a přes D-Bus API už to celkem funguje.
28.2.2013 12:47
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
aniž bych musel číst jakoukoliv dokumentaci.No já bych zase chtěl hodinky s vodotryskem. Ale bonding skrze dvě rozhraní kde druhé při výpadku jednoho to druhé na sebe sveze všechen traffic je bez problémů. Dokonce se mi to (i když dosti hnusným hackem) podařilo rozchodit i mezi dvěma WiFi-nama. Za co bych ale trhal ruce já tohle implementované o jednu vrstvu výše.
28.2.2013 17:17
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
28.2.2013 17:33
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
28.2.2013 17:33
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
28.2.2013 17:18
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Moje otazka byla motivovana touhou vedet, proc bych ho mel na tom serveru nechat. Pocitam, ze redhat ma nejaky duvod, proc ho cpe do defaultni instalace.
On uz tam je ted a je asi prvni vec, kterou vyhodite z kickstartuNikdo nevyhazuje výchozí služby bezdůvodně.
Postup je takovy, ze si clovek prohlidne co vse za sluzby tam je a ty, ktere nemaji na serveru zadny prinos odinstalujeTakových lidí je podle mě beznadějná minorita. Naprostá většina lidí se chová jak jsem psal výše, tedy nevyhazuje věci bez důvodu. Nehledě na to, že nepřínos zmíněných služeb na serveru obecně neplatí. Snad jenom bluetooth se běžně k ničemu nepoužije.
). Mozna jsem opravdu jen prilis konzervativni a moc ovlivneny Unixem
Mozna jsem opravdu jen prilis konzervativni a moc ovlivneny UnixemPopravdě řečeno návrh NetworkManageru je do značné míry taky ovlivněný Unixem i Linuxem, i když si toho nemusíš na první pohled všimnout. Teď nemluvím o jasných návrhových chybách, ale i ty mají v unixovém světě silnou tradici :).
Ale TUI nebo CLI být nemusí – v první řadě musí být perfektně zvládnutý proces úprava konfiguráku → restart služby (znovunačtení konfigurace).Mně se líbí, jak všichni věcí, do být musí a co nemusí, ale každý to ví jinak :).
TUI, GUI, CLI nad tím může postavit klidně někdo třetí a může klidně existovat víc implementací vedle sebe – důležitá je ta dokumentace/standard.My jsme došli k závěru, že by bylo dobré mít jedno slušné standardní CLI. Jistě, jsou různé open source configuration management projekty s vlastním CLI, s alternativami nemám problém. Navíc potřebuješ něco, čím verifikuješ použitelnost API.
– důležitá je ta dokumentace/standard.
Dynamická konfigurace za chodu se dá dělat pomocí nízkoúrovňových nástrojů/příkazů.Jen její část, pokud máš namysli příkazy typu
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
26.2.2013 12:37
26.2.2013 19:52
26.2.2013 23:54
26.2.2013 22:19
ip.
Ja se priznam, ze jsem jeste nenasel odpoved, proc by jsem chtel mit NM na serveru.Ono to není o tom, proč bys ty chtěl mít NetworkManager na serveru. Ani o tom, že by někdo jiný chtěl mít NetworkManager na serveru. Lidi žádají funkcionalitu, kterou NetworkManager momentálně začíná plnit, narozdíl od všech ostatních řešení. Navíc je to spíše náboženská otázka, velká část lidí používá argumenty, které jdou stejně dobře aplikovat i na různé network skripty a podobné. Argument, že NM není na serverech k ničemu beru pouze od lidí, kteří konfigurují své servery jediným shellskriptem pomocí série volání příkazů z balíku iproute (či alternativních nástrojů). Protože podle stejné logiky nejsou na serverech k ničemu ani ty ostatní konfigurátory. Pro osobní flame doporučuju čas po mojí přednášce na InstallFestu nebo jiné konferenci :).
Pro osobní flame doporučuju čas po mojí přednášce na InstallFestu nebo jiné konferenci :).O flame opravdu nemam zajem. Moje otazka nebyla mirena jako provokace a pokud to tak nekdo pochopil, tak se omlouvam. Jde mi opravdu jen o informace. Treba zacnu NM na serverech take pouzivat
To ano. Tak tedy jinak. Jakou fukcionalitu ma NM navic pro server(staticka IP, zadne wlan rozhrani)?Už výše jsem s tebou souhlasil, že pro tvůj server zřejmě nic nepřináší.
O flame opravdu nemam zajem. Moje otazka nebyla mirena jako provokace a pokud to tak nekdo pochopil, tak se omlouvam.Já se omlouvám, slovo flame jsem nemyslel negativně.
Jde mi opravdu jen o informace. Treba zacnu NM na serverech take pouzivatAbys pochopil, k čemu může být podobná služba na serveru, tak musíš začít u sebe. 1) Tvůj úsudek ohledně toho, co je užitečné, může být značně ovlivněn tím, co máš k dispozici a co jsi zvyklý používat. 2) Tvůj názor na to, jak vypadá a jak se používá server se může značně lišit od představy druhého člověka. 3) Představa, že všechny servery na světě mají ručně nastavenou IP je mylná. 4) Představa, že každý chce za všech okolností ovládat síťovou konfiguraci editací skriptu je rovněž mylná. A je toho mnohem víc, na konferencích odpovídám i na zcela konkrétní otázky. A nebo je pokládám. Třeba teď jsem se ptal, zda někdo z publika používá nějaký server konfigurovaný pomocí DHCP a kolik myslíš, že jich zvedlo ruku? Měl bych jim říct, že to dělají špatně, a že server má z definice adresy nastavené vždy ručně?
1) Tvůj úsudek ohledně toho, co je užitečné, může být značně ovlivněn tím, co máš k dispozici a co jsi zvyklý používat. 2) Tvůj názor na to, jak vypadá a jak se používá server se může značně lišit od představy druhého člověka.Je mozne, ze se v enterprise serverech vrtam uz tak dlouho, ze zapominam nekdo muze mit i jine potreby.
3) Představa, že všechny servery na světě mají ručně nastavenou IP je mylná.No je pravda, ze i ja pouzivam par serveru, ktere maji adresu pres DHCP, ale ani tam jsem zadnou vyhodu nenasel.
4) Představa, že každý chce za všech okolností ovládat síťovou konfiguraci editací skriptu je rovněž mylná.No popravde mi prijde o trochu slozitejsi rucni konfigurace NM nez /etc/sysconfig/network-scripts, ktere jsou v RHELu ted. Take je tam system-config-network-tui, ale je pravda, ze kdyz nekdo muze davat na servery X server, tak proc ne NM.
A je toho mnohem víc, na konferencích odpovídám i na zcela konkrétní otázky. A nebo je pokládám. Třeba teď jsem se ptal, zda někdo z publika používá nějaký server konfigurovaný pomocí DHCP a kolik myslíš, že jich zvedlo ruku? Měl bych jim říct, že to dělají špatně, a že server má z definice adresy nastavené vždy ručně?No mame tu dobu v cloudu, takze vlastne proc ne. Jak nad tim premyslim, tak si to dokazu u nekterych sluzeb predstavit.Ja se vetsinou snazim se DHCP na kritickych systemech vyhnout, protoze je to dalsi komponenta, ktera zeslozituje infrastrukturu a snizuje dostupnost sluzeb. Navic kvuli definici sitove komunikace, kterou predavam sitarum by jsem musel na DHCP stejne udelat rezervaci, coz je priblizne stejne pracne jako sit nastavit rovnou lokalne. Dokazu si, ale predstavit, ze nekde ve small bussinesu se takove problemy neresi.
Je mozne, ze se v enterprise serverech vrtam uz tak dlouho, ze zapominam nekdo muze mit i jine potreby.Tak zrovna v enterprise se používá fakt ledacos, pokud je to k dispozici.
No je pravda, ze i ja pouzivam par serveru, ktere maji adresu pres DHCP, ale ani tam jsem zadnou vyhodu nenasel.Třeba bude mít některý z těch serverů dvě síťové karty. Třeba bude některý z nich provozován na dvou verzích IP protokolu. Jednoduchý DHCP klient rozumně zvládá zastat funkci network démona tak u jednoho rozhraní s jednou verzí IP.
No popravde mi prijde o trochu slozitejsi rucni konfigurace NM nez /etc/sysconfig/network-scripts, ktere jsou v RHELu ted.NetworkManager umí /etc/sysconfig/network-scripts a ve Fedoře je dosud ve výchozí konfiguraci používá i pro zápis.
Take je tam system-config-network-tuinmcli teď prochází významnými změnami, stačí se v upstreamovém gitu podívat na větev cli-enhance.
ale je pravda, ze kdyz nekdo muze davat na servery X server, tak proc ne NM.Popravdě řečeno s NM dost počítáme i v initramdisku :), narozdíl od X serveru.
26.2.2013 23:25
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Přiznám se, že by mě také zajímala cílová skupina NetworkManageru.Až na výjimky odpovídá cílové skupině Linuxu.
Asi jsem na tom podobně jako chsajarsa, máme několik desítek (web)serverů s dvěma až třema síťovkama, hromadou ip na každém z nich. Co může v tomhle případě NM nabídnout?To je jako byses mně ptal, co můžu najedenému nabídnout k večeři. Jestliže máš pocit, že všechno potřebné ti tvůj systém už poskytuje, tak není, co řešit.
No a na pracovní stanici je třeba míti navázáno několik (Open)VPN spojení a přes to gnome gui nelze navázat více openvpn spojení.To nemá s GUI nic společného, taková funkcionalita v NetworkManageru není.
Takže vpnky si navazuju ručně. Což mi teda nevadí, právě naopak, alespoň je snadno přístupný log.Mně to trochu vadí z toho důvodu, že se mi tím pádem správně nenakonfiguruje routing a DNS, pokud si různé nástroje myslí, že ta konfigurace je celá jejich. Ale pravděpodobně máš svůj use case vyřešený ke spokojenosti.
Takže NM je jedna z prvních věcí, které vypínám s tím, že se to nějak netrefilo do mého využití a zajímalo by mě, pro koho nebo pro jaké prostředí je to určeno.Já si myslím, že jak z článku, tak z mých talků poslední doby, tak ze změn, které v NM už proběhly, je docela zřejmé, že cílíme na relativně univerzální nástroj. A musím říct, že verze 0.9.8 už začíná docela slušně pokrývat mé představy a potřeby, což není jen tak.
To je jako by ses mně ptal, co můžu najedenému nabídnout k večeři.mno, tohle tak trošku nesedí, spíše je to jako kdybyste se bavili o tom, co bude k večeři příště (až zas bude nějaký stroj instalovat/rekonfigurovat), a on se ptal, proč má mít královskou hostinu o desíti chodech, když se na noc nemá moc jíst a je zvyklý a vyhovuje mu něco malého po studenu ... jistě, z té hostiny si možná vybere nějaký předkrm nebo přílohu nebo zákusek vyhovující jeho stravovacím návykům, ale proč mu má na stole překážet těch ostatních devět talířů?
Jestliže máš pocit, že všechno potřebné ti tvůj systém už poskytuje, tak není, co řešit.a až poskytovat přestane a síť bez NM prostě nenahodí, tak co?
a až poskytovat přestane a síť bez NM prostě nenahodí, tak co?Pokud je nástroj nedostatečný, nebudu si přece stěžovat u autorů jiného nástroje.
Pokud svoje otázky dokážeš položit tak, abych jim rozuměl, pokusím se odpovědět co nepřesněji.existuje zvláštní kategorie otázek, tzv. řečnické, na které není nutno odpovídat výše uvedeným jsem chtěl říci, že tvoje analogie je zcestná; pokud si ji nedokážeš obhájit resp. vyvrátit moji opravu, mohl jsi raději mlčet nežli se uchylovat k takovýmto úskokům
a toto odpovídá na otázku jak?a až poskytovat přestane a síť bez NM prostě nenahodí, tak co?Pokud je nástroj nedostatečný, nebudu si přece stěžovat u autorů jiného nástroje.
a až poskytovat přestane a síť bez NM prostě nenahodí, tak co?Můžeš mi prosím vysvětlit, jak taková situace nastane?
již jsem se reálně potkal s několika bugy, třeba i s návrhem patchů, které se neopravily, protože prostě "NM to řeší" a v initscripts už s tím nikdo nepočítáJo tomu rozumím. A už jsem snad i pochopil tvoji otázku. Tebe ve skutečnosti netrápilo, jestli půjde nahodit síť, ale jestli bude v konkrétní distribuci ještě jiný software, který nahodí síť na základě /etc/sysconfig/network-scripts. Nevím, jestli tohle Herona až tak moc trápí. Jediné, co vím je, že mě to netrápí vůbec.
1.3.2013 13:31
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Až na výjimky odpovídá cílové skupině Linuxu.
Děkuji za konkrétní odpověď 
. Už jen z této diskuse plyne, že to "skoro" všichni vypínají.
To je jako byses mně ptal, co můžu najedenému nabídnout k večeři. Jestliže máš pocit, že všechno potřebné ti tvůj systém už poskytuje, tak není, co řešit.
Potom je ovšem otázkou, proč to v té distribuci vůbec je. Já hledám způsob, jak ty servery administrovat co nejjednodušeji, což prakticky znamená nainstalovat a běžet na výchozím nastavení distribuce. Zatím to vypadá tak, že těch nepotřebných služeb, které po instalaci budu muset exta vypínat, bude přibývat. A funkcionality, kterou by měli řešit, si dělat "ručně".
taková funkcionalita v NetworkManageru není
Takže je to nepoužitelné i na pracovním desktopu 
Ale pravděpodobně máš svůj use case vyřešený ke spokojenosti.
Ano mám. Statické nastavení sítě a ručně spouštěné openvpn.
cílíme na relativně univerzální nástroj
Aby to nedopadlo jak Emacs. Celkem dobrý OS, kterému chybí textový editor
Mě by se líbilo, kdyby to fungovalo jako iptables. Pomocí příkazů iptables (klidně z nějakého generátoru nebo ručně) se nastaví firewall a příkazem service iptables save se persistentně uloží a potom se to automaticky načte při startu os. Je to triviální a dělá to co má.
Takže, kdyby byla možnost si síť nastavit pomocí ip a, ip r atd a potom to jenom uložit, tak bych byl úúúúplně happy.
Děkuji za konkrétní odpověďNicméně jen minimum lidí ho vypíná bezdůvodně.
Takže je to nepoužitelné i na pracovním desktopuAsi jak na kterém. Ale jsem si jistý, že pokud by se našel někdo s chutí se do toho pustit, tak mu rozhodně nebudeme bránit.
Ano mám. Statické nastavení sítě a ručně spouštěné openvpn.Výborně.
Pomocí příkazů iptables (klidně z nějakého generátoru nebo ručně) se nastaví firewall a příkazem service iptables save se persistentně uloží a potom se to automaticky načte při startu os. Je to triviální a dělá to co má.Zhruba tak nějak má NetworkManager v budoucnu fungovat.
Takže, kdyby byla možnost si síť nastavit pomocí ip a, ip r atd a potom to jenom uložit, tak bych byl úúúúplně happy.Ne všechno lze nastavit pomocí
ip route a ip address, je potřeba předat i informace o (per-connection) DNS a dalších mnoha věcech. Ale to, co jde nastavit přes ip by mělo být podporováno přesně tak, jak popisuješ. Jen ti nejsem schopný slíbit datum.
1.3.2013 13:59
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Přiznám se, že by mě také zajímala cílová skupina NetworkManageru.To by me take zajimalo a porad jsem na to jeste neprisel
Ja si treba vzpominam na skoleni RedHatu, kdy u konfigurace site nam by receno asi toto:
"Prvni co po defaultni instalaci je rozumne udelat je vypnout NM. Dalsi dulezita vec je tato polozka v network-scripts(NM_CONTROLLED="no"), kdyby ho tam nekdo zapnul."
Delal jsem si ted takovou malou anketu mezi znamymi na male a statisticky nevyznamne mnozine lidi a ani jeden z nich stejne jako ja nenasel duvod proc NM nechavat na serveru.
Ja se nedivim, te antipatii ohledne NM, protoze to je proste dalsi daemon bezici v systemu. Jak uz jsem rekl na desktopu mu vyznam neubiram, ale do serveru to podle me az na vyjimky(o zadnych takovych nevim) nepatri.
Ja si treba vzpominam na skoleni RedHatu, kdy u konfigurace site nam by receno asi toto: "Prvni co po defaultni instalaci je rozumne udelat je vypnout NM. Dalsi dulezita vec je tato polozka v network-scripts(NM_CONTROLLED="no"), kdyby ho tam nekdo zapnul."To stále platí.
Delal jsem si ted takovou malou anketu mezi znamymi na male a statisticky nevyznamne mnozine lidi a ani jeden z nich stejne jako ja nenasel duvod proc NM nechavat na serveru.Taková anketa nemá žádný význam. Význam pro feature planning by měla anketa typu chcete na serveru používat feature XYZ? (Bez ohledu na název nástroje, který ji poskytne.) Naopak pro verifikaci by byla zajímavá anketa, která by sesbírala důvody, proč ten NetworkManager odinstalovat. Kdo odstraní standardní nástroj bez znalosti toho, o které feature přijde, ten ať se o sebe pak stará sám.
Ja se nedivim, te antipatii ohledne NM, protoze to je proste dalsi daemon bezici v systemu.Popravdě řečeno lidi, kteří mají antipatii k démonům, moc neřeším :). Ti by ideálně neměli používat ani DHCP, pokud to není nezbytně nutné.
do serveru to podle me az na vyjimky(o zadnych takovych nevim) nepatri.Chápu, démoni na servery nepatří ;).
Význam pro feature planning by měla anketa typu chcete na serveru používat feature XYZ?Spravda otazka. Jake feature mi to prinese proti soucasnemu reseni? Dekuji. To je to na co jsem se puvodne ptal, kdyz jsem hledal duvod pro NM pouzivat na serveru. Mozna uz bych mohl dostat konkretni odpoved
Popravdě řečeno lidi, kteří mají antipatii k démonům, moc neřeším :). Ti by ideálně neměli používat ani DHCP, pokud to není nezbytně nutné.Nejde o antipatii k demonum, ale o antipatii ke zbytecnym demonum, kteri nemaji na mem serveru zadny uzitek. S tema pryc.
Chápu, démoni na servery nepatří ;).Po tomhle asi diskuze nema cenu. Ty mas pravdu a ja klid
.
Mozna uz bych mohl dostat konkretni odpovedNemohl, dokud nespecifikuješ své potřeby. A pokud jsou tvé potřeby a přání dostatečně pokryté network skripty, odpovědí je, že ti nepřinese nic. Moje potřeby a představy network skripty pokryté nejsou.
Nejde o antipatii k demonum, ale o antipatii ke zbytecnym demonum, kteri nemaji na mem serveru zadny uzitek. S tema pryc.Fair enough.
Po tomhle asi diskuze nema cenu. Ty mas pravdu a ja klidMně zajímají relevantní argumenty, na poměřování penisů nemám čas.
No mame tu dobu v cloudu, takze vlastne proc ne. Jak nad tim premyslim, tak si to dokazu u nekterych sluzeb predstavit.Ja se vetsinou snazim se DHCP na kritickych systemech vyhnout, protoze je to dalsi komponenta, ktera zeslozituje infrastrukturu a snizuje dostupnost sluzeb.Je pravda, že NM bude muset některé důsledky dynamické konfigurace umět potlačit.
Navic kvuli definici sitove komunikace, kterou predavam sitarum by jsem musel na DHCP stejne udelat rezervaci, coz je priblizne stejne pracne jako sit nastavit rovnou lokalne.Musím říct, že při více strojích v síti mi spíš vyhovují ty rezervace než lokální statická konfigurace. Tím spíš když bych neměl mít pod kontrolou každý z těch strojů.
Dokazu si, ale predstavit, ze nekde ve small bussinesu se takove problemy neresi.Paradoxně nemám dojem, že by hlavní rozdíl dělala velikost businessu.
kteří konfigurují své servery jediným shellskriptem pomocí série volání příkazů z balíku iproute (či alternativních nástrojů)Což mimochodem není vůbec špatný způsob
(tedy za předpokladu, že ten skript nepíšeš ručně, ale vygeneruješ si ho z nějakého hezkého konfiguráku)
Což mimochodem není vůbec špatný způsobJak jsem psal, to jsou ti jediní, kterým ten minimalismus jsem ochotný věřit.
tedy za předpokladu, že ten skript nepíšeš ručně, ale vygeneruješ si ho z nějakého hezkého konfigurákuTak tohle nedělá prakticky nikdo.
proč se tu furt píše o "jediném shellskriptu"Protože tématem bylo používání věcí, které nejsou potřeba. A halda skriptů na to, abych zavolal párkrát ip s různými parametry do toho velmi dobře zapadá.
žádnej otravnej démon ...Náboženské debaty dnes nevedu :).
ach ano, proč tu haldu nespojit do jednoho, vždyť celé zdrojáky NM by taky mohlý být v jednom .c souboru, co na tom, že někdo chce mít třebas parser konfigurace jako knihovnu sdílenou s ostatními skripty apod., to je přeci naprosto zbytečné ...proč se tu furt píše o "jediném shellskriptu"Protože tématem bylo používání věcí, které nejsou potřeba. A halda skriptů na to, abych zavolal párkrát ip s různými parametry do toho velmi dobře zapadá.
žádnej otravnej démon ...Náboženské debaty dnes nevedu :).
# pmap -x 764 764: /usr/sbin/NetworkManager --no-daemon Address Kbytes RSS Dirty Mode Mapping 0000000000400000 988 768 0 r-x-- NetworkManager ... ffffffffff600000 4 0 0 r-x-- [ anon ] ---------------- ------ ------ ------ total kB 357092 8100 2028ah, jistě, to že mám v noťasu jen 4 GiB RAM, o kterou soutěží tuna dalších procesů, je čistě "náboženská otázka", jasně ...
ah, jistě, to že mám v noťasu jen 4 GiB RAM, o kterou soutěží tuna dalších procesů, je čistě "náboženská otázka", jasně ...(hm, a to jsem na tom se svým usecasem notebook vlastně ještě dobře, neb jsem tuhle na půl ucha zaslechl nějakou diskusi o virtuálkách s 256 MiB RAM a že budou muset přejít na víc ...)
~ $ top -p 2658 -p 2644 -b ... PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2658 root 20 0 270m 4876 3500 S 0 0.1 0:04.96 NetworkManager 2644 messageb 20 0 20276 1712 856 S 0 0.0 0:07.04 dbus-daemoJsou tam oproti čistému Debianu ještě nějaké další procesy, nebo to je všechno?
total used free shared buffers cached
Mem: 504940 38568 466372 0 1648 13488
-/+ buffers/cache: 23432 481508
Swap: 392184 0 392184
Pak jsem spustil apt-get install network-manager, rebootnul a dostal toto:
total used free shared buffers cached
Mem: 504940 53440 451500 0 1976 23172
-/+ buffers/cache: 28292 476648
Swap: 392184 0 392184
Čili rozdíl necelých 5MB. Přičemž netuším, k čemu tam je proces modem-manager, který pod Gentoo vůbec nemám...
Čili rozdíl necelých 5MB. Přičemž netuším, k čemu tam je proces modem-manager, který pod Gentoo vůbec nemám...Ten se stará o modemy a jejich specifika, jak napovídá název. Na serveru se bez něj zpravidla obejdeš.
Pokud je potřeba reagovat na události, může tam běžet úplně minimalistický démon, který při události spustí další proces a pak ho zase ukončí a všechny zdroje uvolní.Může být. Pokud přijdeš s konkrétními příklady věcí, které by měly být v NM takto řešené a nejsou, můžem se o tom pobavit.
Dávat tam současný NM by bylo nehorázné plýtvání.Měřil jsi to? Máš nějaké výsledky? Oblasti, které by chtěly zlepšit? Konkrétní návrhy?
a na desktopu bych jím nakrmil NM, zatímco na minimalistickém virtuálu třeba nějaký skript nebo prográmek pro jednorázovou konfiguraci.Nevidím důvod, proč by tu jednorázovou konfiguraci nemohl dělat NetworkManager. Už teď má část funkcionality v dynamických modulech. Vytvářet na to další speciální službu mi přijde kontraproduktivní.
Welcome[de]=Hallo Welcome[fr_FR]=Bonjour Welcome[it]=Ciaoproč se v NM nepoužije aspoň třeba:
dns[1]=127.0.0.1 dns[2]=127.0.0.2 address[1]=172.17.1.101;24 address[2]=172.17.1.101;24místo
dns=127.0.0.1;127.0.0.2 addresses1=172.17.1.101;24; addresses2=172.17.1.102;24;?
Jednotný formát pro popis konfigurace sítě by se hodil k tomu, aby se nemusely vytvářet takové hrůzy a bylo možné si zachovat konfigurační soubor, i když přejdu k jinému nástroji na konfiguraci sítě. Jde o oddělení konfiguračního formátu od implementace – pak spolu může soutěžit víc implementací démona, aniž by uživatelé museli přepisovat konfiguráky z jednoho formátu do druhého.Myslím si, že se mýlíš. Specifikace formátu určuje co všechno lze nastavit a jak se to nastavuje, což je to jediné, o co má vůbec smysl soutěžit. Pokud bude na chlup stejný konfigurák, bude i stejná featureset, a není se o čem bavit. Ten formát musí někdo (detailně) definovat a v tuto chvíli bychom to ideálně byli my. Nativní formát NM není ideální a ve specifikaci chybí formát některých polí. Obojí se dá teoreticky změnit, otázka je, jestli jsou lidi. NetworkManager je opensource s docela přátelskými vývojáři a komunitou, takže každý dobrý nápad je vítán, zvláště od lidí, kteří jsou schopni a ochotni ho dotáhnout až do implementace. Pokud by se to změnilo, vždy je tu poslední možnost forku.
proč se v NM nepoužije aspoň třeba:Na podobné návrhy je vhodnější naše upstream bugzilla než komentáře v Abclinuxu.
Na podobné návrhy je vhodnější naše upstream bugzilla než komentáře v Abclinuxu.Trochu vyhýbavá odpověď (ale čekal jsem to).
address1=172.17.1.101/24 address2=172.17.1.101/24Pokud jde o DNS, tam je mi to úplně jedno. Někde výše jsem ti už psal, proč si myslím, že je to tak, jak to je. Nemá smysl se na to ptát znovu.
ale jsem zvyklý uvažovat ve vrstvách a používat abstrakci.
Na první vrstvě vidím (nebo chci vidět) obecný formát pro zápis nějaké konfigurace. Aby byl tento formát vhodný pro konfiguraci sítě (a obecně čehokoli, co není úplně primitivní), měl by podporovat vícepoložkové volby (vedle mnoha dalších věcí).
Na druhé vrstvě pak vidím konkrétní formát postavený nad tím prvním. Tento druhý formát má nějaký slovník – sadu přípustných voleb případně jejich hodnot (výčtové typy, rozsahy, datové typy…).
kloudnou odpověď jsem z tebe nedostal.Já považuju „je mi to jedno“ v tomto případě za zcela validní odpověď.
Specifikace formátu určuje co všechno lze nastavit a jak se to nastavuje, což je to jediné, o co má vůbec smysl soutěžit. Pokud bude na chlup stejný konfigurák, bude i stejná featureset, a není se o čem bavit.Specifikace určuje maximum* toho, co jde použít. Může být stanoven povinný základ a zbytek je funkcionalita, kterou implementace můžou a nemusí podporovat. Některé z těch vlastností můžou být označené jako „kritické“ (tzn. pokud jsou použity v konfiguráku, implementace je musí podporovat nebo má skončit chybou – a pokud použity nejsou, ničemu jejich nepodpora nevadí), zatímco jiné můžou být ignorovatelné. *) tedy ne úplné, může tam být ještě prostor pro nadstandardní rozšíření
(tedy za předpokladu, že ten skript nepíšeš ručně, ale vygeneruješ si ho z nějakého hezkého konfiguráku)Ono generovat ani neni treba, ja pouzivam zhruba takovyhle popis:
wifi-essid CZF.newtown-stadion wifi-channel 124 wifi-rate 36M ipv4-address 192.168.10.121/29 ipv4-gateway 192.168.10.122A pak mam skript, ktery ty prikazy definuje jako aliasy ($IF je definovan jmenem souboru):
function wifi-essid()
{
iwconfig $IF essid "$1"
}
...
function ipv4-address()
{
ip link set up dev $IF
ip -4 addr add "$1" dev $IF broadcast +
}
...
tedy až na ty konfiguráky, ale to se třeba taky jednou podaří spravitTeď jde o to, které konfiguráky máš namysli, jestli keyfile nebo ifcfg.
Trochu jsem koukal na zdrojáky, ale možná jsem to vzal ze špatného konce (nm-setting-wired.c a spol.). Jak vypadají ty pluginy, jaké mají rozhraní, kde je najdu? Zatím jsem našel jen kód, kterého je nějak hodně na to, jak málo toho dělá. Ale je fakt, že jsem na ten zdroják koukal jen v rychlosti.
Co se týče samotných konfiguráků – pár poznámek/dotazů:
Chtěl bych mít konfiguráky jednotlivých spojení v XML. Dá se to tam při vynaložení nějakého rozumného úsilí doprogramovat? Počítá s tím návrh? Chci mít RelaxNG schéma, abych hned při editaci v Emacsu viděl, jestli tam nemám překlep nebo nepíšu blbosti. Nebo XML Schema pro důkladnější validaci a pro napovídání použitelných voleb v různých dalších editorech.
A jedna připomínka k funkčnosti: je možné používat DHCP a mít to nastavené tak, aby, když bude DHCP server nedostupný, to naběhlo s poslední známou konfigurací? Tzn. při každé úspěšné DHCP konfiguraci si ji někam uložit.
Zatím jsem našel jen kód, kterého je nějak hodně na to, jak málo toho dělá.Já jsem taky našel kód, kterého je hodně na to, jak málo toho dělá. Tak jsem ho zkrátil, což může mimochodem udělat každý. Vždycky mě zajímají konkrétní věci, spíše než obecné kecy.
Kde najdu specifikaci formátu – syntaxe?Je to keyfile. Konfigurační volby jsou zdokumentované například v manuálové stránce
nm-settings. Přesný formát zápisu bohužel zdokumentovaný není, ale každý se může zapojit.
Jak mám vědět, že se booleovské hodnoty píší jako true/false a ne jako yes/no, 0/1 nebo TRUE/FALSE?Nevím. Můžeš zadat do bugzilly, popřípadě rovnou přidat patch, pokud na to máš čas.
Je možná hierarchie sekcí, jak se zapisuje?Konfigurace bohužel není hierarchická a v nejbližší době nebude.
Když je tam routes1 bude tam i routes2 atd.? Jak to mám vědět?Netuším.
(a jak to teprve má někdo parsovat či generovat?)Ideální by bylo, kdyby to nikdo neparsoval ani negeneroval. Snažíme se tvůrce závislých projektů přesvědčit, aby se tomu vyhnuli.
Proč ne aspoň routes.1 či routes#1.Nevidím důvod.
A proč se vícenásobné hodnoty píší jednou tak (addresses1=…) a podruhé jinak (dns=127.0.0.2;127.0.0.1;)?V prvním případě je to tabulka, v druhém případě seznam (počet rozměrů). Předpokládaný počet taky mohl hrát svoji roli.
Proč se maska píše jednou za lomítko a podruhé za středník? Proč je brána od IP adresy jednou oddělena čárkou a jindy středníkem.
commit cca9cfc84d7f458c38ade150754b320ceebc4a42
Author: Pavel Šimerda <psimerda at redhat.com>
Date: Wed Oct 3 14:50:59 2012 +0200
keyfile: read and write a nicer format for IPv4 and IPv6 addresses and routes
You can now use 'address=' even for IPv6 and it's the encouraged way
to set up a single address manually. For multiple addresses,
'address0=', 'address1=', etc, should be preferred.
Example:
address=10.0.0.15/24/10.0.0.1
address0=192.168.0.1/24
address1=10.0.0.16/32
Example (backward compatibility):
addresses=10.0.0.15/24/10.0.0.1
addresses0=192.168.0.1/24
addresses1=10.0.0.16/32
commit 0d82ca5c048cad167c29c456be081ac794710ca5
Author: Pavel Šimerda <psimerda at redhat.com>
Date: Fri Sep 21 16:59:07 2012 +0200
keyfile: unify IPv4/IPv6 address and routing configuration (bgo #682943)
IPv4 and IPv6 address configuration is now handled together and supports
the following syntax (slashes can be replaced with semicolons):
address/plen
address/plen,gateway
IPv4 and IPv6 route configuration is also handled uniformly and supports
the following syntax:
address/plen (for device routes)
address/plen,gateway (for gateway routes)
address/plen,gateway,metric (for gateway routes with metric)
For compatibility reasons, slash (/), comma (,) and semicolon (;) are
considered equal by the parser. The /plen part is optional for both
addresses and routes for compatibility reasons.
Leaving out the prefix length is not considered a good idea. IPv6
addresses default to 64 and IPv4 now defaults to 24 which is the closest
possible IPv4 counterpart. Routes default to single addresses.
Example 1:
[ipv4]
method=manual
addresses1=192.168.56.5/24,192.168.56.1
addresses2=192.168.57.5/24
routes1=4.5.6.0/24
routes2=1.2.3.0/24,4.5.6.7
routes3=7.8.9.0/24,4.5.6.7,99
[ipv6]
method=manual
addresses1=2001:db8:a:b::3/64,2001:db8:a:b::1
addresses2=2001:db8:c:d::3/64
routes1=2001:db8:e:f::/64,2001:db8:a:b::4
Example 2 (equivalent):
[ipv4]
method=manual
addresses1=192.168.56.5;24;192.168.56.1
addresses2=192.168.57.5;24
routes1=4.5.6.0;24
routes2=1.2.3.0;24;4.5.6.7
routes3=7.8.9.0;24;4.5.6.7;99
[ipv6]
method=manual
addresses1=2001:db8:a:b::3;64;2001:db8:a:b::1
addresses2=2001:db8:c:d::3;64
routes1=2001:db8:e:f::;64;2001:db8:a:b::4
For writing, I have arbitrarily chosen one of the formats 'reader'
can parse. Address and prefix length are separated by slash (/),
everything else is separated by comma (,).
addresses1=address/plen,gateway
routes1=address/plen,gateway,metric
Note: The modified 'reader' exposes a bug in the 'writer' and ignores
out badly-formatted routes. This problem is also fixed by this
commit. Keyfile tests now pass.
Jak na to mám jako uživatel přijít?Patches welcome.
Kde najdu specifikaci podporovaných voleb?Generuje se ze zdrojáků, pokud jsem to správně pochopil.
Je to někde ve strojově čitelné podobě?Nějaký meziformát se myslím během kompilace generuje. Pokud nestačí, tak patches welcome.
Mám možnost si zkontrolovat správnost konfigurace i jinak, než že restartuji NM a budu doufat, že naběhne nebo vypíše smysluplnou chybovou hlášku?Technicky to jde zajistit jen do určité míry a na to kód je, takže přidat daný tool by nemusel být až takový problém, pokud by někdo měl zájem se do toho pustit.
Chtěl bych mít konfiguráky jednotlivých spojení v XML.Mně XML připadá na konfiguraci nepříliš vhodné, ale to asi víš.
Dá se to tam při vynaložení nějakého rozumného úsilí doprogramovat?Dá.
Počítá s tím návrh?Vždyť máme konfigurační pluginy pro několik různých distribučních konfiguračních formátů!
A jedna připomínka k funkčnosti: je možné používat DHCP a mít to nastavené tak, aby, když bude DHCP server nedostupný, to naběhlo s poslední známou konfigurací?Snažíme se dodržovat standardy, a do toho používání neplatné konfigurace dost dobře nezapadá.
Tzn. při každé úspěšné DHCP konfiguraci si ji někam uložit.To dhclient dělá.
Snažíme se dodržovat standardy, a do toho používání neplatné konfigurace dost dobře nezapadá.Není to neplatná konfigurace, je to zcela legitimní volba – jako uživatel říkám (zaškrtnutím nějaké volby, která zatím chybí):
nastav síť podle DHCP serveru (resp. obecně nějaké autokonfigurace dané serverem) a pokud server není dostupný, nastav ji tak, jak byla minule (včera, před týdnem, při posledním restartu… prostě minule).Modelová situace: doma mám X počítačů a dnes na nich mám statické IP adresy – aby byla síť decentralizovaná a bylo možné spojení, i když se sít takřka úplně rozpadne, server/router je mimo a zbudou mi online třeba jen dva počítače a jeden switch (nebo jen kabel). DHCP by bylo elegantnější, protože bych mohl IP adresy a další nastavení spravovat centrálně. Ale v současné době to za to riziko nestojí. Pokud bych ale měl jistotu, že počítače po restartu naběhnou s nastavením, které měly posledně, použil bych to. Další uplatnění by byla farma strojů, u které chceš minimalizovat závislost na centrálním serveru (serverech), ale zároveň tam nechceš ty IP adresy nastavovat ručně nebo je chceš občas z centra změnit (pak by ještě bylo dobré ty „příkazy“ podepisovat). Nikde netvrdím, že to má být výchozí chování, ale využití to podle mého má – a je celkem rozumné předpokládat, že když se server neozývá, platí stále to, co nám řekl minule. Ostatně proč by mělo záležet na tom, zda se klientský stroj restartoval nebo ne? Když se nerestartuje, tak si taky drží původní adresu.
Vždyť máme konfigurační pluginy pro několik různých distribučních konfiguračních formátů!Tak jsem je našel, akorát mne už trochu přechází chuť:
$ cloc ./src/settings/plugins/ifcfg-rh/
defined(%hash) is deprecated at /usr/bin/cloc line 1277.
(Maybe you should just omit the defined()?)
126 text files.
116 unique files.
98 files ignored.
http://cloc.sourceforge.net v 1.53 T=0.5 s (56.0 files/s, 46834.0 lines/s)
--------------------------------------------------------------------------------
Language files blank comment code
--------------------------------------------------------------------------------
C 9 3201 1506 17819
make 3 31 1 203
C/C++ Header 7 76 173 171
Bourne Again Shell 8 16 21 168
XML 1 2 0 29
--------------------------------------------------------------------------------
SUM: 28 3326 1701 18390
--------------------------------------------------------------------------------
A to si lidi stěžují, že Java nebo XML jsou ukecané. Skutečně je potřeba osmnáct tisíc řádků na načítání konfigurace?
Někdy je program lepší přepsat… v tomto případě asi do C++.
P.S. pro zajímavost statistika jednoho systému v Javě, který toho dělá řádově víc než NM:
------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- Java 812 19489 36049 84605 XML 20 111 34 1689 XSD 1 6 6 48 XSLT 1 7 7 43 ------------------------------------------------------------------------------- SUM: 834 19613 36096 86385 -------------------------------------------------------------------------------A pro srovnání celková statistika NM:
$ cloc NetworkManager-0.9.8.0
defined(%hash) is deprecated at /usr/bin/cloc line 1277.
(Maybe you should just omit the defined()?)
1109 text files.
1078 unique files.
415 files ignored.
http://cloc.sourceforge.net v 1.53 T=3.0 s (229.7 files/s, 109931.7 lines/s)
--------------------------------------------------------------------------------
Language files blank comment code
--------------------------------------------------------------------------------
C 233 27764 22769 133881
HTML 73 250 0 46748
Bourne Shell 23 6199 7339 43277
m4 22 1242 368 11949
C/C++ Header 213 3351 6040 8922
XML 36 256 1 3322
make 65 662 146 2571
XSLT 2 59 20 617
Perl 1 68 38 464
Python 5 85 74 253
CSS 1 18 31 217
C++ 4 64 121 178
Bourne Again Shell 8 16 21 168
Ruby 3 39 86 101
--------------------------------------------------------------------------------
SUM: 689 40073 37054 252668
--------------------------------------------------------------------------------
Jasně, počty řádků nejsou všechno a sám jsem tu kritizoval, když se někdo snažil minimalizovat počet řádků za každou cenu, ale trochu to o něčem vypovídá.
Skutečně je potřeba osmnáct tisíc řádků na načítání konfigurace?Není. Vybral sis konfigurační plugin pro ifcfg-rh, což je konfigurace network skriptů, která je z principu dost komplikovaná a nikdy nebude podporovaná úplně (jedná se o shell skript, který se snažíme číst jako konfigurační soubor). A ǐ když se tam podívám, tak to těch tvých osmnáct tisíc řádků vůbec nemá.
Někdy je program lepší přepsat…V kontextu v jakém to píšeš se jedná o plácnutí do vody na základě nesprávných a nezpracovaných informací. Nejlepší bude se tvářit, jako kdybys nic nenapsal.
v tomto případě asi do C++.Nepatřím mezi lidi, kteří vidí spásu světa v přepisu software do C++.
P.S. pro zajímavost statistika jednoho systému v Javě, který toho dělá řádově víc než NM:Jsi si jistý, že dokážeš smysluplně posoudit, co NM dělá a co ty jednotlivé soubory znamenají a proč tam jsou?
Jasně, počty řádků nejsou všechno a sám jsem tu kritizoval, když se někdo snažil minimalizovat počet řádků za každou cenu, ale trochu to o něčem vypovídá.A ty počty řádků v NetworkManageru budou pravděpodobně narůstat, mimo jiné i kvůli testům. O čem to bude vypovídat potom?
A i když se tam podívám, tak to těch tvých osmnáct tisíc řádků vůbec nemá.Tady jsem asi měl dopsat nějaké vysvětlení, proč se naše měření neshodují:
$ cloc src/settings/plugins/ifcfg-rh/tests/
119 text files.
101 unique files.
105 files ignored.
http://cloc.sourceforge.net v 1.56 T=0.5 s (28.0 files/s, 30778.0 lines/s)
--------------------------------------------------------------------------------
Language files blank comment code
--------------------------------------------------------------------------------
C 2 1944 836 10513
make 4 178 114 1599
Bourne Again Shell 8 16 21 168
--------------------------------------------------------------------------------
SUM: 14 2138 971 12280
--------------------------------------------------------------------------------
Ano, deset tisíc řádků testů v céčku taky o něčem vypovídá a není to moc lichotivé – stačil by jeden generický test + data (vstup + očekávaný výstup).Viz níže.
Ale už toho nechme, nebudu ti do toho kecat, protože vím, že všude je dost shnilého kódu a není čas to všechno opravit hned…Každý dobrovolník vítán :).
jedná se o shell skript, který se snažíme číst jako konfigurační soubor)Je to dřina, než se váš temperament zjemní. Než opravdu dozrajete. Ale ten požitek, ten za to stojí.
tak tam vysedává mbieblA čeká na bratra s lodí, jež dováží čaj a kávu.
jedná se o shell skript, který se snažíme číst jako konfigurační souborTohle mi přijde jako chybné rozhodnutí. Proč se nad takovým (beztak nereálným) úkolem tráví čas, proč někdo musel napsat těch osmnáct tisíc řádků a proč se radši nevěnoval něčemu užitečnému? Staré skripty doslouží, nějakou dobu můžou být podporované a sepíše se k tomu upgradovací procedura, podle které se uživatel snadno dopracuje k deklarativní (nikoli procedruální) konfiguraci sítě. (pokud jsou nějaké procedury potřeba, dají se ty skripty pouštět jako v Debianu – ale bude v nich jen to, co nejde zapsat deklarativně).
Tohle mi přijde jako chybné rozhodnutí.Tohle rozhodnutí naštěstí není moje a tak ho nemusím obhajovat. Nicméně z business pohledu je to nejen dobré rozhodnutí, ale momentálně i jediné možné, takže nemám ani důvod remcat.
Proč se nad takovým (beztak nereálným) úkolem tráví čas, proč někdo musel napsat těch osmnáct tisíc řádků a proč se radši nevěnoval něčemu užitečnému?Vzhledem k tomu, že se někdo rozhodl těch osmnáct tisíc řádků (pokud počítáš testy) někdo zaplatit (na tomhle nikdo nebude pracovat dobrovolně), z pohledu tvých oblíbených neoliberálních teorií by měla být taková práce považována za užitečnou, ne? Nemyslím si, že má smysl vůbec posuzovat ifcfg-rh z hlediska užitečnosti široké komunitě.
jen vyjadřuji určité pochybnosti a říkám, že bych to dělal jinakJen jsem vyjádřil odlišný názor.
Pokud chce někdo používat staré konfiguráky, tak může nasazení NM odložit a jet postaru.To zní jako kdyby NM byly jen konfigurační soubory, což není pravda.
Až bude chtít NM použít, tak si ručně přepíše konfiguraci do nového formátu.To je jedna z věcí, do které nikoho nutit nechceme.
Skutečně se tady automatizace vyplatí?Jsem o tom přesvědčen.
Shodou okolností jsem nedávno taky dělal na jednom nástroji pro upgrade konfiguraceTohle je read-write plugin, který umožňuje přejít z network skriptů na NetworkManager, aniž bys musel zahodit konfigurační formát. Pro tebe je to možná bezvýznamné, já bych se bez toho jako uživatel taky obešel. Ale pro projekt to v redhatím světě znamená, že nabízíme možnost přejít na NetworkManager bezbolestně. V tomto ohledu jsme na tom o dost lépe než třeba systemd. Ty můžeš vzít klasický redhatí konfigurační soubor a jednou direktivou rozhodnout, zda se o něj budou starat klasické network skripty nebo NetworkManager. A to stejné můžeš udělat s celým systémem, tzn. když nenecháš NetworkManager vůbec spustit, network skripty se postarají o vše, co dokážou. Navíc mnohé nástroje v tuto chvíli generují konfiguráky v redhatím formátu a bude trvat roky všechny přesvědčit, aby přešli na D-Bus API, zvlášť když zatím musejí udržovat i stávající řešení, protože NetworkManager zatím nedospěl do stádia, kdy můžeme všem říct, aby network skripty zahodili. A to stádium není jenom o funkcích, ale o desítkách dalších věcí včetně důvěry v samotný projekt. My nejsme takoví kingové, abychom mohli říct po vzoru systemd: „Serem na vás, od teď je všechno jinak a vy se prostě přizpůsobíte.”
ale to byly řádově stovky řádků kódu a i tak bylo kolem dost pochybností, jestli to stojí za to.I kdybych na to já změnil názor, tak to na výsledku stejně nic nezmění :).
(v tomto případě)
Jinak 8k řádků kódu + 10k řádků testů pro načítání konfigurace v RH je opravdu síla. Což ale není myšleno ani moc jako kritika autorů NM (musel bych znáẗ detaily), spíš asi budou ty konfiguráky dost šílené + se to autor snažil napsat naprosto neprůstřelně.
Java a XML jsou ukecané, to jen C/GObject je asi ještě ukecanějšíTím to tak úplně není. Podívej se na ty zdrojáky sám.
Jinak 8k řádků kódu + 10k řádků testůOno je to něco jako 6800 řádků kódu, z toho 4400 pro writer a 2200 pro reader (200 v různých pomocných souborech). Je dost pravděpodobné, že během vývoje nebyly to zdrojáky úplně moc refactorovány a nesou si s sebou zbytečnou historickou zátěž. Pokud jde o testy, kterých je 10500 řádků, tak ty budou mít na první pohled tak 400% overhead, takže pokud se někdo cítí na otročinu, tak po refactoringu bych to viděl na 2500 řádků. Pokrytí je kolem 75% podle řádků, což není až takový zázrak. Nicméně to napovídá, že v céčkovém kódu by testy nemusely přesáhnout 4000 řádků, když si necháme rezervu na doplnění nějakých chybějících vlastností. Malá ukázka z testů (bez komentáře):
»·······/* ===== WIRED SETTING ===== */ »·······s_wired = nm_connection_get_setting_wired (connection); »·······ASSERT (s_wired != NULL, »······· "minimal-wired-verify-wired", "failed to verify %s: missing %s setting", »······· TEST_IFCFG_MINIMAL, »······· NM_SETTING_WIRED_SETTING_NAME); »·······/* MAC address */ »·······array = nm_setting_wired_get_mac_address (s_wired); »·······ASSERT (array != NULL, »······· "minimal-wired-verify-wired", "failed to verify %s: missing %s / %s key", »······· TEST_IFCFG_MINIMAL, »······· NM_SETTING_WIRED_SETTING_NAME, »······· NM_SETTING_WIRED_MAC_ADDRESS); »·······ASSERT (array->len == ETH_ALEN, »······· "minimal-wired-verify-wired", "failed to verify %s: unexpected %s / %s key value length", »······· TEST_IFCFG_MINIMAL, »······· NM_SETTING_WIRED_SETTING_NAME, »······· NM_SETTING_WIRED_MAC_ADDRESS); »·······ASSERT (memcmp (array->data, &expected_mac_address[0], sizeof (expected_mac_address)) == 0, »······· "minimal-wired-verify-wired", "failed to verify %s: unexpected %s / %s key value", »······· TEST_IFCFG_MINIMAL, »······· NM_SETTING_WIRED_SETTING_NAME, »······· NM_SETTING_WIRED_MAC_ADDRESS); »·······ASSERT (nm_setting_wired_get_mtu (s_wired) == 0, »······· "minimal-wired-verify-wired", "failed to verify %s: unexpected %s / %s key value", »······· TEST_IFCFG_MINIMAL, »······· NM_SETTING_WIRED_SETTING_NAME, »······· NM_SETTING_WIRED_MTU);
Ideální by bylo, kdyby to nikdo neparsoval ani negeneroval. Snažíme se tvůrce závislých projektů přesvědčit, aby se tomu vyhnuli.Na wordovské dokumenty je taky lepší nesahat přímo, nesnažit se pochopit a implementovat jejich formát a zavolat binárku MS Wordu nebo nějakou MS knihovnu… Přijde mi to ve stylu: neumíme napsat specifikaci nebo je totálně zprasená a nelogická, tak na to raději nekoukejte a použijte naši jedinou správnou implementaci.
Zatím jsem našel jen kód, kterého je nějak hodně na to, jak málo toho dělá.Taky tak, to byl přesně můj dojem, když jsem naposled koukal do zdrojáku NM. Ale tak třeba pro to mají nějaký důvod...
27.2.2013 12:37