Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »Richard Stallman přednáší ve středu 7. května od 16:30 na Technické univerzitě v Liberci o vlivu technologií na svobodu. Přednáška je určená jak odborné tak laické veřejnosti.
Jean-Baptiste Mardelle se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 25.04.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
TmuxAI (GitHub) je AI asistent pro práci v terminálu. Vyžaduje účet na OpenRouter.
Byla vydána nová verze R14.1.4 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5, Wikipedie). Přehled novinek i s náhledy v poznámkách k vydání. Podrobný přehled v Changelogu.
Bylo vydáno OpenBSD 7.7. Opět bez písničky.
V Tiraně proběhl letošní Linux App Summit (LAS) (Mastodon). Zatím nesestříhané videozáznamy přednášek jsou k dispozici na YouTube.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.czroot=. Na jiném to potřebovalo ovladač filesystému, MD raidu, řadiče a grafické karty - hádám, že ten zdržel boot natolik, aby jádro v mezičase stihlo nadetekovat zbytek hardware a initramfs byl schopen nabootovat. A není nic lepšího, než tohle řešit ve tři ráno, protože jiný stroj se stejným hardware při testování nic z toho nepotřeboval...
3.8.2019 16:48
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="aa:bb:cc:dd:ee:00", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="aa:bb:cc:dd:ee:01", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
Jeden z největších problémů s koncepcí "predictable names" je v tom, že na rozdíl od např. blokových zařízení nejde u síťových rozhraní udělat něco jako symlink. U blokových zařízení může udev nechat původní jméno od jádra jako skutečné jméno a k němu pak přidat několik aliasů - by-id, by-path, by-uuid, …, zatímco síťové rozhraní může mít jen jedno, takže je potřeba vybrat jeden způsob pojmenování.
Naštěstí to vypadá, že by tohle omezení v dohledné době mohlo padnout, takže by časem udev mohl nechávat jména rozhraní na pokoji a vytvářet aliasy podle různých schémat, jako to funguje u blokových zařízení.
IMHO je poměrně slušná šance že to půjde, koneckonců to byli právě lidé okolo systemd/udev, kdo přišel s tím, že se zařízení nebudou přejmenovávat, ale pouze vytvářet symlinky. Takže pokud bude možné používat stejný model i pro síťová rozhraní, mělo by jim to vyhovovat. Navíc vývojáři systemd nemívají zábrany nechat systemd natvrdo záviset na nějaké poměrně nové featuře jádra. Třeba závislost na kdbus plánovali ještě dřív, než se kdbus dostal do jádra (což je o to pikantnější, že se tam nakonec nedostal).
Mimochodem, ne všechno zlo světa má na svědomí Lennart Poettering, pachatelem "predictable names" je Kay Sievers.
5.8.2019 15:10
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Newer versions of udev take more of these attributes into account, improving (and thus possibly changing) the names and addresses used for the same devices.Fakt si na základě toho manu někdo troufne uhodnout, jaké jméno bude mít další přidaná síťovka? Dřív to šlo, pokud si člověk udržoval udev rules na základě MAC, mohl si jméno pro novou síťovku (pokud věděl její mac) zapsat jako další pravidlo a po přidání tohle jméno skutečně dostala. Dneska lze akorát tak strčit kartu do PC a potom najít jejich jméno a doufat, že už se nikdy nezmění. Jinak, fyzické stroje s jednou integrovanou síťovkou. Odhadl by někdo jejich jména?:
enp3s0 enp2s0Kdyby nějakou náhodou ta síťovka byla na PCI bus 0 (proč je zrovna v Intel NUC na trojce ví asi jen intel), tak se tam to
p nepíše a bylo by to ens0. Kdyby náhodou firmware oznámil index, tak by se jmenovaly eno0. Nic prediktivního na tom není. Otázkou je, zda je to vůbec stabilní napříč verzemi udev (tj, pokud se nová verze udev naučí číst firmware těchto strojů, jestli se to nepřejmenuje na eno0).
Dřív, pokud bylo potřeba přehodit kartu ze slotu do slotu (nebo popřeházet jejich pořadí), přiřazené jméno zůstalo stejné (na základě mac). Dnes, kdyby tohle někdo udělal, tak si může přepsat všechny konfiguráky.
5.8.2019 17:38
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Proto bylo potřeba to zrušit a zavést tenhle systém předvídatelných jmen, které jsou v každém hardware stejné™ (some restrictions apply)Chápu, že ten odstavec je ironie, ale tohle u těchto jmen neplatí už tuplem. Nenašel jsem doma dvě pecka, kde by byly stejné a očekávané názvy síťovek. Integrované síťovky se vesele liší deska od desky, síťovky v PCIE mají různá jména. Očekávám, že ty sloty nebudou očíslované ani podle fyzického pořadí na desce, takže při přehození to dostane opět nepredikovatelný název. Přenositelnost OS moc nehrozí. Kdežto u starého systému stačilo přepsat udev rules tak, aby jména síťovek odpovídala jejich použití a nic jiného (tj nastavení sítě, iptables, bridge apod.) se už dál měnit nemuselo. V okamžiku, kdy se mi z enp3s0 stane eno0, tak to musím přepsat. Btw proč teda nikdo nepřišel s možností si nastavit kompletně vlastní název síťovky? Vnitřně ať to má path dle fyzického zapojení, ale proč tomu nemůžu dát alias
eth-wan apod.?
Mimochodem ve FreeBSD (kde se by default síťovky pojmenovávají podle driveru - em0 intel, re0 realtek apod), lze udělat:
It is also possible to rename an interface by doing: ifconfig_ed0_name="net0"přímo v
rc.confu
Už nějakou dobu říkám, že by každý měl být donucen aspoň dva roky používat svůj výtvor a pro vývojáře to platí dvojnásob. Přejmenovávat síťovky na názvy typu enp2s3b1flpzv9 by je hodně rychle přešlo, kdyby to párkrát museli vypisovat do konzole na serveru, který nechce bootovat a plánovaná odstávka se tak pomalu ale jistě mění v neplánovaný výpadek.Asi tak nějak.
5.8.2019 20:26
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
značná část funkcionalit v systemd je tímto motivovaná a řeší ty problémy velmi dobřeProblém je v tom, že to přidělává problémy tam, kde žádné nebyly
Přesto se systemd většina distribucí rozhodla adoptovat.Ano, přesto se vývojáři distribucí rozhodli nové schéma pojmenování síťovek použít. Proto říkám, že by to teď měli za trest několik let používat. A tím nemyslím na svém pracovním laptopu, ale jako lidi odpovědní za to, že běží nějaká služba.
Pokud by fungovalo správně onboard / slot -based pojmenování, nevidím v novém přístupu problém.Tak si znovu přečtěte #13 . Problém nového přístupu je, že rozbíjí starý přístup a nepřináší adekvátní náhradu, přičemž cenu za tuhle změnu pak nesou uživatelé. A brát si uživatele za rukojmí, aby se vytvářel tlak na výrobce HW, to je taky super přístup...
Problém nového přístupu je, že rozbíjí starý přístupStarý přástup je možné jednoduše zapnout přes "net.ifnames=0" boot parametr. Ta "stará" udev pravidla by pak myslím také měla fungovat.
a nepřináší adekvátní náhraduToto: https://www.freedesktop.org/software/systemd/man/systemd.link.html mi přijde jako více než adekvátní náhrada.
A jak často přehazujete disky ze serveru do serveru?Docela často, buď se ten server chová divně, nebo zákazník chce víc výkonu, nebo tak něco. Problém je v tom, že takový přesun často není do stejného hardware a persistentní názvy jsou... no, to už je popsáno v #13 Takže tak jako tak se musí něco udělat, jenže od doby "stabilních" jmen to něco nefunguje spolehlivě.
6.8.2019 13:54
michich | skóre: 51
| blog: ohrivane_parky
proč teda nikdo nepřišel s možností si nastavit kompletně vlastní název síťovkyTu možnost přece máš. Můžeš mít vlastní udev pravidla, kterými zařízením přiřadíš libovolná jména (ovšem vyhni se jmennému prostoru ethX kvůli možnému souběhu s objevením nových rozhraní kernelem). Nebo můžeš jména přiřazovat pomocí systemd.link(5).
6.8.2019 14:24
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
6.8.2019 18:17
michich | skóre: 51
| blog: ohrivane_parky
CHANGES WITH 209:
[...]
* udev gained a new scheme to configure link-level attributes
from files in /etc/systemd/network/*.link. These files can
match against MAC address, device path, driver name and type,
and will apply attributes like the naming policy, link speed,
MTU, duplex settings, Wake-on-LAN settings, MAC address, MAC
address assignment policy (randomized, ...).
[...]
— Berlin, 2014-02-20
6.8.2019 20:29
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
7.8.2019 09:36
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
KillUserProcesses=yes). A úplně nakonec si k tomu napíšu sám sobě článek. Ale stále mám nálepku systemd hatera.
Takže musíte dělat práci za systemd evangelisty, za distro a ještě za it novináře 
8.8.2019 02:22
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Jinak, fyzické stroje s jednou integrovanou síťovkou. Odhadl by někdo jejich jména?Já teď zažil následující: stroj, integrované síťovky
enp5s0 a enp6s0 (ok, whatever). Přidal jsem do PCIe kartu se dvěma SFP sloty. Ty se pojmenovaly ens4f0 a ens4f1. A ty onboard síťovky se tím přejmenovaly na enp7s0 a enp8s0. WTF!!
Trochu nepříjemné na tom persistent modelu bylo to, že když člověk vyměnil síťovou kartu v počítači s jednou, tak ta nová dostala nové jméno. Ale to je věc, která se nestane "sama od sebe" (aspoň u skutečného hardware), takže je na to admin připravený a pak ten soubor prostě odedituje. U "predictable" modelu se může stát (a děje), že se jméno změní bez toho, aby admin sahal na hardware.
Trochu horší bylo, že existují virtualizační prostředí, kde stejné rozhraní stejného virtuálu dostane při každém bootu jinou MAC adresu. Setkal jsem se s tím kdysi u Hyper-V, ale i tam to naštěstí šlo vypnout. Potom na to IIRC nadávali ti, kdo často migrovali VM mezi hosty.
tohle se hrozne hodi, kdyz neco v serveru umre.Trochu nepříjemné na tom persistent modelu bylo to, že když člověk vyměnil síťovou kartu v počítači s jednou, tak ta nová dostala nové jméno. Ale to je věc, která se nestane "sama od sebe" (aspoň u skutečného hardware), takže je na to admin připravený a pak ten soubor prostě odedituje.
9.8.2019 09:11
michich | skóre: 51
| blog: ohrivane_parky
MACAddressPolicy jde přece vypnout, ať už globálně nebo třeba jen pro bridge. Jako default dává nové chování (persistent) pro bridge smysl. Ano, neočekávána změna chování byla samozřejmě problém. Ta změna byla dokumentovaná v NEWS, ale zřejmě ne dost jasně (hint o bridge tam Yu přidal až dodatečně po objevení té SUSE BZ). Když používám rolling distro, tak mě podobné problémy nesmí šokovat. Zbyszek byl v reakci na oznámení problému vstřícný. Uznal, že ta změna měla být představena pod novou verzí schématu a dodatečně ji zavedl. Tak nepřeháněj, že ti systemd usurpuje práva.
Jako default dává nové chování (persistent) pro bridge smysl.
Za prvé: jak komu. Za druhé: za starých dobrých časů (TM) bývalo zvykem, že při zavedení podobné volby se jako default použila ta hodnota, která se chovala stejně jako dosud (nebo aspoň co nejblíže dosavadnímu chování). Ale to holt bylo před systemd…
9.8.2019 11:26
michich | skóre: 51
| blog: ohrivane_parky
Tiskni
Sdílej:
