Byla vydána nová verze 5.4.0 programu na úpravu digitálních fotografií darktable (Wikipedie). Z novinek lze vypíchnout vylepšenou podporu Waylandu. Nejnovější darktable by měl na Waylandu fungovat stejně dobře jako na X11.
Byla vydána beta verze Linux Mintu 22.3 s kódovým jménem Zena. Podrobnosti v přehledu novinek a poznámkách k vydání. Vypíchnout lze, že nástroj Systémová hlášení (System Reports) získal mnoho nových funkcí a byl přejmenován na Informace o systému (System Information). Linux Mint 22.3 bude podporován do roku 2029.
GNU Project Debugger aneb GDB byl vydán ve verzi 17.1. Podrobný přehled novinek v souboru NEWS.
Josef Průša oznámil zveřejnění kompletních CAD souborů rámů tiskáren Prusa CORE One a CORE One L. Nejsou vydány pod obecnou veřejnou licenci GNU ani Creative Commons ale pod novou licencí OCL neboli Open Community License. Ta nepovoluje prodávat kompletní tiskárny či remixy založené na těchto zdrojích.
Nový CEO Mozilla Corporation Anthony Enzor-DeMeo tento týden prohlásil, že by se Firefox měl vyvinout v moderní AI prohlížeč. Po bouřlivých diskusích na redditu ujistil, že v nastavení Firefoxu bude existovat volba pro zakázání všech AI funkcí.
V pořadí šestou knihou autora Martina Malého, která vychází v Edici CZ.NIC, správce české národní domény, je titul Kity, bity, neurony. Kniha s podtitulem Moderní technologie pro hobby elektroniku přináší ucelený pohled na svět současných technologií a jejich praktické využití v domácích elektronických projektech. Tento knižní průvodce je ideální pro každého, kdo se chce podívat na současné trendy v oblasti hobby elektroniky, od
… více »Linux Foundation zveřejnila Výroční zprávu za rok 2025 (pdf). Příjmy Linux Foundation byly 311 miliónů dolarů. Výdaje 285 miliónů dolarů. Na podporu linuxového jádra (Linux Kernel Project) šlo 8,4 miliónu dolarů. Linux Foundation podporuje téměř 1 500 open source projektů.
Jean-Baptiste Mardelle se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 25.12.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
OpenZFS (Wikipedie), tj. implementace souborového systému ZFS pro Linux a FreeBSD, byl vydán ve verzi 2.4.0.
Kriminalisté z NCTEKK společně s českými i zahraničními kolegy objasnili mimořádně rozsáhlou trestnou činnost z oblasti kybernetické kriminality. V rámci operací OCTOPUS a CONNECT ukončili činnost čtyř call center na Ukrajině. V prvním případě se jednalo o podvodné investice, v případě druhém o podvodné telefonáty, při kterých se zločinci vydávali za policisty a pod legendou napadeného bankovního účtu okrádali své oběti o vysoké finanční částky.
Ahoj, prosím o radu s podivným problémem.
Stáhl jsem si předinstalovaný VMWare obraz Solarisu (SXDE). Spustil jsem ho ve VMWare. Všechno fungovalo hladce, včetně sítě (NAT, vmnet8). Ve firefoxu se dalo normálně surfovat.
Po několika restartech se ale síť začala chovat divně. Nelze zobrazit žádnou webovou stránku ve Firefoxu, nefunguje HTTP ani FTP. Firefox (v rozporu s realitou) tvrdí, že nemůže stránku nalézt. Zkoušel jsem to i pod rootem, ale situace je navlas stejná.
Kupodivu však funguje ssh z virtuálního stroje ven (tj. kamkoliv na Internetu), a to pod rootem i pod normálním uživatelem. Dál pod rootem zcela normálně funguje dig a vrací správné hodnoty. Příkaz netstat -rn vrací routovací tabulku, která vypadá v pořádku a odpovídá situaci. Stejně dobře funguje i route get.
Zkoušel jsem znovu spustit konfigurační skript VMWare i restartovat VMWare včetně všech jeho služeb, ale nic nepomáhá.
Důležitá poznámka: Mám tam ještě druhý virtuální stroj: PC-BSD. Funguje bez problémů, včetně webu. Přitom je připojen ke stejé síti vmnet8. (Nikdy nespouštím oba stroje najednou.) Nikdy tam nebyly problémy s resolvingem nebo se sítí obecně. Taky jde o předinstalovaný obraz.
Ne, ssh neresolvuje. Musel jsem tam zadat IP adresu ručně. Doménová jména odmítá s tím, že je nezná. Jediné, co opravdu resolvuje, je dig. 
Ale ping na IP adresu (vnější) normálně funguje a v routovacích tabulkách se správně inkrementuje počítadlo použití gateway.
Podivný je hlavně fakt, že jsem už v tom Solarisu normálně surfoval a fungovalo to. Pokud si dobře vzpomínám, jednou jsem pak zapomněl před spuštěním vmware spustit i jeho služby. Když jsem nabootoval Solaris, síť (pochopitelně) nefungovala. Tedy jsem ho (korektně) vypnul a restartoval jsem vmware se zapnutými službami. Jenže síť už se nevzpamatovala. Jako by se pouhým restartem v tom Solarisu něco změnilo. To mě trochu děsí, protože mi to připomíná Windows. (!)
Všude ve výpisech je rozhraní vmxnet0, zatímco při bootování se objevují hlášky, že nebylo možné inicializovat zařízení pcn0 pomocí DHCP. Konkrétně failed to plumb pcn0 a pár dalších hlášek. (Nejspíš je v Solarisu odlišen název fyzických zařízení od rozhraní síťové vrstvy (případně VLAN). Nebo je to jiný důvod?)
Následuje výpis ze session, která přesně dokumentuje podivné chování. Resolving přes dig funguje, ale ostatní programy neresolvují. Pod výpisem z terminálu je vždy odpovídající výstup příkazu snoop, který ukazuje, že se na síti opravdu něco děje.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
ping# ping 217.112.173.73 217.112.173.73 is alive # ping charon.podzimek.org ping: unknown host charon.podzimek.org
10.84.53.64 -> 217.112.173.73 ICMP Echo request (ID: 1268 Sequence number: 0) 217.112.173.73 -> 10.84.53.64 ICMP Echo reply (ID: 1268 Sequence number: 0)
Poznámka: druhý ping se vůbec nepokusil resolvovat. Prostě nezná a hotovo...
dig# dig andrej.podzimek.org ; <<>> DiG 9.3.4-P1 <<>> andrej.podzimek.org ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1688 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;andrej.podzimek.org. IN A ;; ANSWER SECTION: andrej.podzimek.org. 259200 IN CNAME charon.podzimek.org. charon.podzimek.org. 259187 IN A 217.112.173.73 ;; AUTHORITY SECTION: podzimek.org. 259187 IN NS charon.podzimek.org. ;; Query time: 72 msec ;; SERVER: 10.84.53.2#53(10.84.53.2) ;; WHEN: Tue Nov 6 17:17:31 2007 ;; MSG SIZE rcvd: 88
10.84.53.64 -> 10.84.53.2 DNS C andrej.podzimek.org. Internet Addr ? 10.84.53.2 -> 10.84.53.64 DNS R andrej.podzimek.org. Internet CNAME charon.podzimek.org.
Poznámka: Taktéž dig andrej.podzimek.org @217.112.173.73 funguje správně. Snoop pak ukáže:
10.84.53.64 -> 217.112.173.73 DNS C andrej.podzimek.org. Internet Addr ? 217.112.173.73 -> 10.84.53.64 DNS R andrej.podzimek.org. Internet CNAME charon.podzimek.org.
sshVýpis je dlouhý, proto ho sem nedávám. Výsledek je přesně stejný jako v případě ping. Při zadání konkrétní IP adresy funguje ssh bez problémů. Při zadání doménového jména se vůbec nepokusí resolvovat a ohlásí chybu.
# ssh andrej@217.112.173.73 andrej@217.112.173.73's password: Last login: Tue Nov 6 16:47:42 2007 from vpn-friends.ms.mff.cuni.cz [andrej@charon ~]$ exit logout Connection to 217.112.173.73 closed. # ssh andrej@charon.podzimek.org ssh: charon.podzimek.org: node name or service name not known
Co se tyce toho vmxnet0 vs. pcn0, tak co si matne pamatuju, tak VMware emuluje AMD PCnet kartu
Ne všechny. V novějších verzích je to (přinejmenším pro 64-bitové hosty) gigabitový Intel (Pro/1000 nebo jak se to oficiálně jmenuje).
(přinejmenším pro 64-bitové hosty)
Tenhle je 32-bitový (host i guest).
fgrep hosts /etc/nsswitch.conf
hosts: files
Soubor /etc/resolv.conf by měl být v pořádku. Původně tam bylo:
domain: localdomain nameserver: 10.84.53.2Zkoušel jsem tam dát svůj domácí nameserver nebo servery poskytovatele, ale výsledek je pořád stejný.
ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
vmxnet0: flags=201004843<UP,BROADCAST,RUNNING,MULTICAST,DHCP,IPv4,CoS> mtu 1500 index 2
inet 10.84.53.65 netmask ffffff80 broadcast 10.84.53.127
ether 0:c:29:0:61:26
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
inet6 ::1/128
Děkuji mnohokrát za radu, už mi to funguje. Problém s nsswitch.conf jsem už řešil kdysi dávno v Linuxu, ale vůbec mě nenapadlo, že v Solarisu to bude podobné.
Problém se síťovým rozhraním vznikl skutečně po instalaci VMWare Tools, kdy byl původní „hardware“ nahrazen nějakým lepším, rychlejším. Takže odstraněním pcn0 z /etc se to vyřešilo.
Kdo změnil soubor nsswitch.conf, to zůstává záhadou. Při prvním bootu resolving normálně fungoval... Na tohle už asi nepřijdu. Hlavní je, že to teď funguje.
Tiskni
Sdílej:
