Byl publikován přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie) za uplynulé dva měsíce. Servo zvládne už i Gmail. Zakázány jsou příspěvky generované pomocí AI.
Raspberry Pi Connect, tj. oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče, byla vydána v nové verzi 2.5. Nejedná se už o beta verzi.
Google zveřejnil seznam 1272 projektů (vývojářů) od 185 organizací přijatých do letošního, již jednadvacátého, Google Summer of Code. Plánovaným vylepšením v grafických a multimediálních aplikacích se věnuje článek na Libre Arts.
Byla vydána (𝕏) dubnová aktualizace aneb nová verze 1.100 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.100 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.5.
OpenSearch (Wikipedie) byl vydán ve verzi 3.0. Podrobnosti v poznámkách k vydání. Jedná se o fork projektů Elasticsearch a Kibana.
PyXL je koncept procesora, ktorý dokáže priamo spúštat Python kód bez nutnosti prekladu ci Micropythonu. Podľa testov autora je pri 100 MHz približne 30x rýchlejší pri riadeni GPIO nez Micropython na Pyboard taktovanej na 168 MHz.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 12.0. Přehled novinek v aktualizované dokumentaci.
Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-05-06. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Pravděpodobně se jedná o poslední verzi postavenou na Debianu 12 Bookworm. Následující verze by již měla být postavena na Debianu 13 Trixie.
Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
Aké problémy? Ja mám ako obyčajný súbor a nevšimol som si problémy s fuse.
Root se přece může přes su
přepnout na tebe a pak ten připojený FS vidí…
Áno, to môže.Čímž ovšem celé tvoje vlákno nabývá jaksi komický nádech.
Ale napriamo to neuvidí.Já si naopak myslím, že to uvidí úplně napřímo, on se totiž může napřímo podívat do jakéhokoli tvého procesu přes
/proc
.
Je to taká obskúrna bezpečnosť,Není to obskurní bezpečnost. Ani jiná.
To, áno. Predstava že má nejaký správca implementované sledovanie užívateľov aby sa v prípade ich pripojenia mohol prepnúť na užívateľa aby im mohol kontrolovať ich dáta pripojené cez fuse je naozaj komická. Týmto smerom to ovšem stočili miestny troli čo poznajú tak maximálne jednoužívateľskú inštaláciu.Můžeš mi nějak vysvětlit motivaci psaní tohoto odstavce?
Ja som písal o probléme keď root mohol cez df vidieť užívateľmi pripojené disky cez fuse. Ono, keď máš systém s pripojenými niekoľkými tisíckami užívateľov, a desiatkami aplikačných diskov, tak je mierne nebezpečné ak by pri kontrole vyťaženia diskov videl správca o niekoľko stoviek diskov viac. Ak by to bolo vidno, tak zblbne aj automatický monitoring cez SNMP.Jestli to správně chápu, tak je ti příjemné spoléhat se na to, že je správce idiot, a především bysis přál, aby vývojáři od takového správce idiota odstínili co nejvíce informací. To je všechno hezké a srozumitelné, problém ovšem vidím v absenci motivace na straně adminů a vývojářů, kteří o vyplnění tvých představ společně rozhodují.
Predpokladám, že si správca.Pro účely této diskuze je tvůj předpoklad chybný. Nespravoval jsem systémy, ke kterým běžně dostávají cizí lidé shellovské účty, a ani se na to v nejbližší době nechystám. Momentálně správa systémů ani nepatří mezi mé hlavní činnosti.
Ak si však moje slová nepochopil, tak mi skús prezradiť ako by sa choval SNMP monitoring zaplnenia diskov keby sa fuse prípojné body zobrazovali každému, vrátane roota.Nevidím smysl do obecné diskuze zatahovat implementační detaily. Stejnětak nevidím smysl v tom, že zde mícháš skrývání informací před administrátorem a konkrétní technický problém. Nedává mi nejmenší smysl řešit tyto dvě věci jako jedno téma.
Ak si ten model doteraz nepochopil, tak si sa ohodnotil správne.Obávám se, že tvůj pokus o invektivu v kontextu diskuze vyznívá poněkud směšně.
zvyšnými diskutérmi čo tiež nevideli viacužívateľské systémyZ výše citovaného se obávám, že jsi opravdu příliš zmatený, abych ti plně porozuměl a možná i příliš na to, abychom mohli vést smysluplnou diskuzi.
Je naprosto nemožné, aby bylo součástí FreeBSD něco podobného systemd.Naprosto nemozne?! Vase presvedceni bych obcas potreboval. Po vyjadreni lidi jako je Jordan Hubbard bych rekl, ze je to jen otazkou casu nez budou mit neco s podobnou funkcionalitou.
Ve světě BSD funguje odjakživa řád a systematický přístup.To je pak skoro na svatoreceni.
Jednak to není chaos, ale zdravá konkurence a zkoušení různých nových cest. A jednak ve světě BSD máš zase FreeBSD, OpenBSD, NetBSD a různá další *BSD… takže by dávalo spíš smysl srovnávat FreeBSD a Ubuntu nebo FreeBSD a SUSE atd.
Jednak to není chaos, ale zdravá konkurence a zkoušení různých nových cest.Takže ten chaos, o kterém psal předřečník není chaos, ale něco jiného? Tomu říkám reakce k věci.
Systemd protlačuje RedHat silou, ostatní se podřizují z obav kvůli kompatibilitě.[citation needed]
ostatní se podřizují z obav kvůli kompatibilitě
I kdyby ano – tak by to byl právě důvod, proč vyvinout náhradu s kompatibilním API, která nebude trpět nevýhodami systemd, ne?
Ako niečo s kompatibilným api k niečomu čo nemá zdokumentované api a kažou stotinkovou verziou sa mení? Keby to bolo tak jednoduché tak tu už dávno alternatíva existuje. Lenže systemd je kopa služieb ktoré medzi sebou nejako komunikujú a napísať čo i len k jednej z tých služieb alternatívu, ktorá by držala paritu s nezdokumentovaným API je práca na celý úväzok.
Pokud je nějaká aplikace závislá na systemd, tak není závislá na celém systemd, ale jen na nějaké jeho části. A tu aplikaci musel někdo podle nějaké specifikace/dokumentace napsat. A snad nechceš říct, že se ty aplikace při každé setinkové verzi systemd rozbíjejí nebo je nutné je přepisovat, ne? Takže by stačilo napsat náhradu jen k té malé části systemd, na které něco závisí.
A tu aplikaci musel někdo podle nějaké specifikace/dokumentace napsat.Tento předpoklad může být i zcela chybný.
A snad nechceš říct, že se ty aplikace při každé setinkové verzi systemd rozbíjejí nebo je nutné je přepisovat, ne?Kompatibilita aplikace s novými verzemi systemd (ač samozřejmě nezaručená) vůbec neimplikuje kompatibilitu náhrady systemd s novými verzemi aplikace se systemd kompatibilní. Obávám se, že se tady jedná o vražednou kombinaci logického faulu s absencí aplikace zkušeností.
Takže by stačilo napsat náhradu jen k té malé části systemd, na které něco závisí.Ano, stačilo, nicméně to typicky nelze napsat z dokumentace, ale podle toho, co aplikace skutečně využívají. Stačí se podívat na projekty jako Wine a musí to být snad každému jasné, jak se tyhle věci dělají a jaké to má důsledky.
„Připadne mi, že celý linuxový svět nesnáší systemd“
Čo tak anketu?
A ani to neni tak jednoduche, protoze molochy jako je systemd anebo gnome, kde vsechno komunikuje se vsim pres zpravy neni uplne snadne pochopit.
Ta složitost kódu a počet řádek hraje taky roli, ale podstatné je i to, že překompilovat si takový LibreOffice, Firefox, KDE, Gnome atd. není jen tak – vyžaduje to nějakou prvotní přípravu prostředí a pak hodně diskového prostoru, paměti a procesorového času. Tady by hodně pomohlo, kdyby Byla k dispozici virtuálka s připraveným prostředím, kterou bych si pustil buď u sebe nebo by běžela na nějakém společném serveru a já si jen přes SSHFS připojil zdrojáky, upravil pár řádků a za chvíli bych viděl výsledek (buď v té virtuálce nebo bych si stáhl balíčky pro svoji distribuci).
Přečti si definici svobodného softwaru:
In order for freedoms 1 and 3 (the freedom to make changes and the freedom to publish the changed versions) to be meaningful, you must have access to the source code of the program. Therefore, accessibility of source code is a necessary condition for free software. Obfuscated “source code” is not real source code and does not count as source code.
Podobná podmínka je v definici otevřeného softwaru:
Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.
Tam se explicitně mluví o záměrně obfuskovaném kódu, což se dá pochopit, protože definici svobodného/otevřeného softwaru nejde postavit na „kvalitě“ – ta je v tom tomto smyslu subjektivní a nejde říct, že kód zkušeného programátora je svobodný, zatímco nedokonalý kód začátečníka je nesvobodný.
Z tohoto pohledu by šlo za svobodný software považovat jen velmi malou část softwaru – protože většina programů obsahuje chyby a nějaká „temná místa“, která způsobují horší čitelnost a udržovatelnost. Program tvořený 100% čistým a přehledným kódem je spíš výjimka.
Další věc je, že binární software (bez dostupných zdrojáků), jehož licence umožňuje úpravy, se v praxi v podstatě nevyskytuje – takže nemá smysl o téhle kategorii ani moc uvažovat.
Když se vrátím k té tvojí posloupnosti:
Je tu jasná hranice:
1-4 je svobodný software (resp. záleží na licenci) a do které kategorie patří, je značně subjektivní – někomu se bude dobře číst i ten assembler a zase nebude chápat programy v jiných jazycích, protože je nezná. Někdo se snadno zorientuje v sto tisíc řádků dlouhém programu a někdo se ztratí i ve stořádkovém skriptu. A takový Perl, C, C++ nebo funkcionální jazyky jsou pro hodně lidí dost nečitelné – zatímco ti, kdo je používají každý den s nimi nemají problém.
5-7 je jednoznačně nesvobodný software – nelze ho vydat pod svobodnou/otevřenou licencí (chybí zdrojáky). Je to software, který byl záměrně vytvořen (vygenerován) tak, aby se nedal studovat a upravovat. Autor záměrně neposkytuje zdrojové kódy, aby ostatním znemožnil zkoumání a vývoj toho programu.
Z tohoto pohledu by šlo za svobodný software považovat jen velmi malou část softwaruJa sem nerikal, ze tu hranici chci posunout.
1-4 je svobodný software (resp. záleží na licenci) a do které kategorie patří, je značně subjektivníAno, je to subjektivni, a o to prave jde. Misto toho, aby spolu lidi diskutovali co je pro koho jeste prijatelne, tak se ridi podle nejakych minimalnich pozadavku shury a detaily ignoruji, prestoze se jedna o stale tentyz problem. Rozdil obtiznosti modifikace 1 a 4 muze byt i vetsi, nez u 4 a 5. Ne ze by kagorie 5 byla prelidnena, pokud trpis uzkostlivou potrebou dodrzovat vsechny zakony, vetsinou tam budou asi historicke binarky, u kterych se autor vyjadril ve smyslu "delejte si s tim co chcete". Ale mnozstvi takovych pripadu nijak nemeni pointu toho co rikam.
Zdrojovy kod je taky meziprodukt, kterym vyvojar vyjadril svou myslenku.Bavíme se stále ještě o definici svobodného software?
Pokud je to tak špatné, tak je to obfuskace kódu, o které se v definici píše a není to zdrojový kód a tím pádem ani svobodný software.
Přijde mi, že se zbytečně chytáš nějakých nesmyslných okrajových případů – extrémně špatné zdrojáky, které „nejdou“ upravovat, a na druhé straně binárky, ke kterým sice nemáš zdroják, ale autor ti dal právo je měnit a „v pohodě“ si ten assembler upravíš. IMHO je zcestné se tímhle zabývat nebo na tom stavět kritiku, protože tyhle případy prakticky nenastávají.
Pokud bych mel ja zvolit nejjednodussi definici z pravniho pohledu, tak zvolim tu, co jsem zminil vyse, ze proste nikdo nikoho nebude trestat za pokus o zmenu. Obvykle pouzivana definice je daleko slozitejsi.
Právně závazná je licence, ne definice – ta říká, jaké to má pozadí, jaký to má smysl a proč to tak je. Stejně jako spousty článků na GNU.org.
RMS dal mnohokrat najevo, ze si vsechno nadefinuje jak mu to pripada nejlepsi vzhledem k jeho vysnenemu modelu spolecnosti, a vubec si nebude lamat hlavu s tim, ze se to bude muset formalizovat gigantickym pravnickym humusem.
RMS (a spousta dalších lidí) má nějakou představu, co je správné a jak by se měl dělat software. Jak tyhle myšlenky implementovat pomocí zákonů a licencí, to je práce pro právníky. Mě (a zjevně ani RMS a další) nezajímá „nejjednodušší definice z právního pohledu“, ale zajímá nás to, co je správné. Zákony a licence jsou jen nástroj, jak toho cíle dosáhnout.
BTW: nejde napsat zákon tak, aby pro jeho aplikaci nebylo potřeba používat rozum, nebo aby ho nějaký troll nemohl napadnout s tím, že v 0,000000001 % případů nefunguje tak, jak by měl. Ostatně existuje něco jako litera zákona, jeho doslovné znění, a duch zákona, ta myšlenka a podstata za ním. Soudce musí respektovat oboje a nemůže tupě strojově aplikovat jen ten doslovný text.
Jinak pripad kdy mam binarku+dokumentaci jsem vubec nerozebiral. Porovnaval jsem situace, kde mam binarku, binarku+zdrojak a binarku+zdrojak+dokumentaci.
Nevím, co na tom chceš rozebírat nebo v čem je tady problém.
Mě (a zjevně ani RMS a další) nezajímá „nejjednodušší definice z právního pohledu“, ale zajímá nás to, co je správné. Zákony a licence jsou jen nástroj, jak toho cíle dosáhnout.Vzdyt to jsem v podstate napsal.
Nevím, co na tom chceš rozebírat nebo v čem je tady problém.Uz jsem to psal nekolikrat - z pohledu RMS je neposkytnuti zdrojaku spatne, protoze pro uzivatele je tezke ten SW menit - respektive autor ma vyhodu oproti komukoli jinemu, kdo by ho chtel menit. Ja jenom rikam, ze napriklad neposkytnuti dokumentace muze taky zvysit obtiznost zmeny, prestoze ne tolik jako neposkytnuti zdrojaku, a jedna se tedy stale o stejny problem.
Kdybys někde ukradl třeba zdrojáky Windows (nějaké kusy se někde snad i povalují)GitHub - WinNT4 20 rokov starý ale niekoho by to mohlo zaujímať :D
k dispozici virtuálkaTohle bych já právě nechtěl. Tímto směrem směřují (někteří) používatelé (zejména) Dockeru, tedy že si připraví prostředí (stylem, až se to rozjede, tak to vydáme) a je to velmi křehké a od počátku rozbité. Měla by být snaha spíše opačná, aby stačilo dostatečně obecné prostředí.
Připadne mi, že celý linuxový svět nesnáší systemd, ale zatím nikdo neudělal použitelný fork. Je to tak? Proč?Nevím, jestli platí tvá premisa, ale vím, že tvá logika je naprosto vadná. Jestliže lidem vadí systemd, proč by ho v první řadě měli vyvíjet?
kdyz je SystemD na tolik spatny, a neoblibeny (soude podle toho, ze na nej nadavaji i Red Hat-aci) proc se tedy rve do distribuci?
Protože Gnome 3 funguje jenom pod systemd. A správci distribucí podle všeho nemají odvahu Gnome 3 úplně vykopnout.
Protože Gnome 3 funguje jenom pod systemd.Bullshit. Treba OpenBSD zde.
Cela vec je jeste vice postavane na hlavu: kdyz je SystemD na tolik spatny, a neoblibeny (soude podle toho, ze na nej nadavaji i Red Hat-aci) proc se tedy rve do distribuci?Presne preto, prečo sa do distribúcií dostalo libav.
Kazdej by chtel do raje, ale umrit - to uz ne!Dalsi kapitolou jsou pak linuxaru nostalgicky zvlikajici po dobach, kdy vrcholem moznosti konfigurace systemu by Emacs, nebo Vi
/etc/mtab nemůže být normální soubor, ...
To zní, jako by šlo o něco skandálního a bylo na tom něco špatného. Přitom je to spíš naopak. Proč bych měl mít v adresáři /etc/
nějaký automaticky generovaný soubor, který se každou chvíli mění? Do tohoto adresáře patří konfigurace, kterou si chci udržovat ručně, případně pomocí nějakého nástroje, chci si ji verzovat, sledovat v ní změny atd. A ne aby se v ní soubory samy dynamicky měnily. To jsou věci, které patří do /var/
, /run/
nebo ideálně nějakého virtuálního FS, který není fyzicky uložen na disku, jako je /proc/
nebo /sys/
.
To by v podstate znamenalo ze naborenej filesystem s /etc nepujde spravit bez uplne zbytecnych oklik.Možná mě někdo z kolegů opraví, ale ohledně opravy
/etc
ze systemd bootovaného z toho kterého systému bych si nedělal velké naděje. Pokud je to vůbec schopné nabootovat, tak se to snaží člověka minimálně devadesát sekund zdržet, aby to aspoň neměl zadarmo.
No práve, že si nie som istý, či by vôbec mal mtab byť v etc. Podľa mňa je to skôr aktuálny stav než konfigurácia a mal by byť len v /proc.
To mi je jasné. Len nevidím dôvod prečo to od začiatku nebolo v /proc. Informácia o práve namontovaných fs je predsa jednoznačne stav a nie konfigurácia.
/etc/resolv.conf
.
Nesúhlasím. Obsah resolv.conf zaujíma akurát tak userspace. Je to konfigurácia resolvera, často statická (127.0.0.1). Niektoré nástroje ho generujú, ale to ešte neznamená, že je stav. Zoznam pripojených filesystémov na rozdiel od resolv.conf nemôžem len tak upraviť a dúfať, že sa tomu systém prispôsobí.
Nesúhlasím.Životní postoj nebo nesouhlasíš s něčím konkrétním?
Obsah resolv.conf zaujíma akurát tak userspaceÚplně stejně jako obsah
/etc/mtab
?
Je to konfigurácia resolveraNeříkej.
často statická (127.0.0.1).Často statická, často dynamická, co z toho plyne?
Niektoré nástroje ho generujú, ale to ešte neznamená, že je stav.A?
Zoznam pripojených filesystémov na rozdiel od resolv.conf nemôžem len tak upraviť a dúfať, že sa tomu systém prispôsobí.Je pravda, že
/etc/mtab
je větší nesmysl než /etc/resolv.conf
a že v případě trvale používaného resolveru na localhostu a trvalé konfigurace domén lze obsah /etc/resolv.conf
, výchozí konfigurace prakticky všech distribucí je však v tuto chvíli odlišná.
Životní postoj nebo nesouhlasíš s něčím konkrétním?
Nesúhlasím s tým, že resolv.conf je stav niečoho. Resolver nie je služba, nebeží, nemôže mať teda stav. resolv.conf je teda konfigurácia. Že ju niektorý softvér upravuje na tom nič nemení. Takto by sme z /etc mohli vyhodiť aj konfiguráciu grubu pretože väčšinou ju tiež generuje softvér automaticky.
Úplně stejně jako obsah /etc/mtab?
/etc/mtab nič nekonfiguruje. Mal by obsahovať +/- aktuálny stav pripojenia diskov (teda stav kernelu).
výchozí konfigurace prakticky všech distribucí je však v tuto chvíli odlišná
Mám doma len gentoo a ubuntu (okrem embedded kde si to riešim cez connman a /etc mám namontovaný ro). Ubuntu má statickú konfiguráciu 127.0.0.1. V gentoo mám statickú konfiguráciu. Ako je to u iných distribúcií netuším.
Nesúhlasím s tým, že resolv.conf je stav niečoho.To, že ve výchozí konfiguraci běžně používaných distribucí při zapojení do běžné sítě je
/etc/resolv.conf
generovaný a obsahuje výhradně stav a nikoliv uživatelskou konfiguraci, považuju za natolik zjevný fakt, že se obávám, že už tou první větou zabíjíš celý příspěvek.
Resolver nie je služba, nebeží, nemôže mať teda stav. resolv.conf je teda konfigurácia.Non sequitur. Navíc je tady řeč o tom, zda je obsah
resolv.conf
součástí uživatelské konfigurace nebo součást stavu systému. V mnohých zcela běžných případech zjevně platí to druhé.
/etc/mtab nič nekonfiguruje.O tom zde nemám v plánu polemizovat.
Ubuntu má statickú konfiguráciu 127.0.0.1.Pokud vím, tak výchozí konfigurace Ubuntu používá NetworkManager s nastavením
dns=dnsmasq
, kdy /etc/resolv.conf
zapisuje NetworkManager a konfigurace /etc/resolv.conf
je generována. Neměnný seznam nameserverů na tom nic nemění, dokonce to není jediný údaj v tomto souboru.
V gentoo mám statickú konfiguráciu.Není náhodou v Gentoo stále
/etc/conf.d/net
a /etc/resolv.conf
tím pádem při typickém použití opět generovaným souborem?
Ako je to u iných distribúcií netuším.
/etc/resolv.conf
primárně jako generovaný soubor, ať už přes NetworkManager, /etc/conf.d/net
nebo dhcpcd.
/etc/resolv.conf
, je to bug a je potřeba ho nahlásit. :)
Konfigurace je fstab
, kdežto mtab
je aktuální stav systému. Podobné je to s tím resolv.conf
– u mě to vypadá např. takhle:
# ll /etc/resolv.conf lrwxrwxrwx 1 root root 29 dub 14 2013 /etc/resolv.conf -> ../run/resolvconf/resolv.conf
Je to stav, kdežto /etc/network/interfaces
je konfigurace.
U stavu (který je odvozený z konfigurace nebo třeba z DHCP serverů a jde ho kdykoli obnovit) mi přijde nežádoucí až škodlivé, aby se kvůli němu muselo fyzicky zapisovat na disk. Zvlášť u těch zařízení, která často běží z nějaké flashky, nic zapisovat nechceš. Ale vadí mi to i na PC – už z principu, je to nesystémové a taky kvůli verzování.
Což je taky chyba. Podle mého do /etc/
nic generovaného nepatří. Patří tam šablony konfiguráků nainstalované při instalaci programů a potom hlavně jejich ručně upravené verze a další konfiguráky přidané správcem.
Všechno ostatní by mělo být v jiných složkách a v /etc/
by měl být jen předpis, jak toho dosáhnout – např. „zeptej se DHCP serveru 8.8.8.8 a ulož si DNS servery“.
zeptej se DHCP serveru 8.8.8.8 a ulož si DNS servery
Resolver nie je služba. Nemá stav, nemá si kam zapísať aké sú DNS servery získané z DHCP. Nerieši sa to zápisom do /etc len tak zo srandy.
Na druhej strane je možné urobiť si readonly systém kde v /etc/resolv.conf nastavím "nameserver 127.0.0.1" a spustím službu, ktorá bude fungovať ako DNS (povedzme aj s cachovaním a podobnými nechutnosťami).
Ja napr. v embedded hračkách používam connman, ktorý sám funguje ako DNS. Beží ako služba, ktorá si z dhcp zistí dns servery (ak je teda tak nakonfigurovaný) a podľa nich resolvuje. Aktuálne DNS servery sa dajú zmeniť ce dbus rozhranie.
A proč si neuložit DNS servery třeba někam do /run/network
a v /etc
udělat jen symbolický odkaz?
/run
, /run/network
by teoreticky příslušel službě /etc/init.d/network
, která ovšem touto schopností nedisponuje. Jinak debianí resolvconf
se symlinkem taky pracuje.
Nemá stav, nemá si kam zapísať aké sú DNS servery získané z DHCP.To mi ovšem zní jako jedno velké nedorozumění, mezi funkce resolveru nepatří seznam DNS serverů zapisovat. Zmíněný connman je trochu něco jiného, resolving je jen jedna z jeho funkcí.
Osobně spíš nechápu proč se to u zprávy o novém systemd vůbec nějak zdůrazňuje.Pretože správa obsahuje prvé dve položky zo zoznamu noviniek z ohlásenia tej novej verzie.
Tiskni
Sdílej: