Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
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.
Oficiální stanovisko vyšlo před nějakým časem v blogu : FreeNAS Corral Status: From “RELEASE” to “TECHNOLOGY PREVIEW” Status
Skoro tři roky vývoje FreeNAS Corral byly zahozeny. Všem je doporučeno provést downgrade zpět na verzi 9.10.
Na stránkách projektu již není ke stažení Correl verze.
Migrace na starší verzi není zajištěna a vzhledem k úplně odlišným konfiguračním souborům se neplánuje implementace automatické migrace (slovy vývojářů : FreeNAS je open source projekt s volně dostupnými zdrojovými kódy, nikomu nebráníme to implementovat, my to dělat nebudeme).
Manuální migrační proces je popsán zde : FAQ: Migrating from FreeNAS Corral to FreeNAS 9.10 / 11.
Kdo si dal tu práci a zrušil Jaily a přešel na Corral a Docker, má smůlu, vše bude muset znovu ručně zpátky přemigrovat, nebo počkat na podporu VM a migrovat do VM.
Ten, kdo provedl migraci do KVM, by měl počkat na FreeNAS 11, který podporu KVM dostane.
Čumím jak puk, nemohu tomu stále uvěřit a osobně čekám na stable 11, aktuálně je venku FreeNAS 11.0-RC s podporou VM (KVM) a přepracovaným UI.
Pravdou ovšem je, že mně trápí tři věci na Corralu, jednou je divně se chovající Veeam backup (skoro to i vypadá časově na dobu, kdy byl proveden upgrade na Corral) a druhým problémem je to, že Start/Stop/Restart VM způsobí, že FreeNAS přetočí síťovky a celý server je na síti 30s nedostupný. Poslední chybou to, že pokud mám nastaveno na síťovce MTU 9000, tak VM nesputím, nebo když spustím, tak v ní není ethernet, protože se snaží nastavit MTU na 1500 v bridgi s MTU 9000 a nejde to obejít.
Všem kdo neupgradovali na FreeNAS 10 tímto gratuluji. Těm, co upgradovali a nedělali skoro žádné změny a nechali si snapshot se starší verzí FreeNAS, přeji, aby downgrade proběhl bez problémů. Těm, co si snapshot nenechali, nebo dělali hodně změn (vytvářeli datasety, upgradovali pool apod.), s těmi prosím soucítím a nezávidím jim nevratnou slepou uličku :-/.
Zdar Max
Tiskni
Sdílej:
Start/Stop/Restart VM způsobí, že FreeNAS přetočí síťovky a celý server je na síti 30s nedostupný.Určitě to dělá? Tohle se občas děje i při normální práci s bridgem, když se do něj přidávají/ubírají síťovky - automaticky se mění jeho MAC adresa, s čímž se zbytek sítě nemusí srovnat hned.
ix2: link state changed to UP lagg1: link state changed to UP vlan0: link state changed to UP vlan1: link state changed to UP nfsd: can't register svc name NLM: local NSM state is 0 bridge0: Ethernet address: 02:42:64:09:55:00 bridge0: changing name to 'mgmt0' bridge1: Ethernet address: 02:42:64:09:55:01 bridge1: changing name to 'nat0' tap0: Ethernet address: 00:bd:d1:9e:fa:00 bridge2: Ethernet address: 02:42:64:09:55:02 ix2: promiscuous mode enabled lagg1: promiscuous mode enabled bridge2: link state changed to UP vlan0: promiscuous mode enabled tap0: promiscuous mode enabled bridge2: changing name to 'brg12' tap0: link state changed to UP tap0: link state changed to DOWN tap0: promiscuous mode disabled brg12: link state changed to DOWN ix2: promiscuous mode disabled lagg1: promiscuous mode disabled vlan0: promiscuous mode disabled tap0: Ethernet address: 00:bd:9c:34:fd:00 bridge2: Ethernet address: 02:42:64:09:55:02 ix2: promiscuous mode enabled bridge2: link state changed to UP lagg1: promiscuous mode enabled vlan0: promiscuous mode enabled tap0: promiscuous mode enabled bridge2: changing name to 'brg12' tap0: link state changed to UP tap0: link state changed to DOWN tap1: Ethernet address: 00:bd:30:31:0d:01 tap1: promiscuous mode enabled tap1: link state changed to UP tap1: link state changed to DOWN tap2: Ethernet address: 00:bd:d3:07:0f:02 tap2: promiscuous mode enabled tap2: link state changed to UP tap2: link state changed to DOWN tap0: promiscuous mode disabled tap1: promiscuous mode disabled tap2: promiscuous mode disabled brg12: link state changed to DOWN ix2: promiscuous mode disabled lagg1: promiscuous mode disabled vlan0: promiscuous mode disabled ix2: Interface stopped DISTRIBUTING, possible flapping tap0: Ethernet address: 00:bd:47:9b:81:00 bridge2: Ethernet address: 02:42:64:09:55:02 ix2: promiscuous mode enabled lagg1: promiscuous mode enabled bridge2: link state changed to UP vlan0: promiscuous mode enabled tap0: promiscuous mode enabled bridge2: changing name to 'brg12' tap0: link state changed to UPDalší věc je třeba nemožnost změnit MTU z UI bez restartu. Měl jsem na lagg nastaveno MTU9000, změnil jsem na 1500, server byl 30s nedostupný, poté web ksicht hlásil MTU 1500, ale přes ssh jsem viděl, že není nastaveno, změny se skutečně aplikovaly až po rebootu.
Samozřejmě na síti mám normálně RSTP, ale to Linux asi neumí.Neumí, bohužel. Hodilo by se.
Important note! MSTP part of the code (as opposed to STP/RSTP part) is mainly untested, so I believe it will behave unexpectedly in many situations. Don't use it in production!To nezní moc dobře. Nehledě na to, že by to spíš mělo být v kernelu, ne v user space.
jj taky jsem zkoušel různé, nakonec jsem šel do ubuntu serveru (protože jsem líný prase). Možnost tam cokoliv přidat...
aktuálně
- tvheadend
- 4tunerový dvb-s2 (tbs-6985)
- oscam s skylink kartou
- samba/nfs
- 3x4TB mdraid
- dhcp/dns/routing
- lxd kontejnery s grafováním provozu/teplot/senzorů (grafana + influx), webserver
Jako jednorázová řešení jsou ok, ale jak si začnete hrát, zkoušet, mít více nároků, tak stejnak skončíte u nějakých "plnotučných" řešeních. Na freenasu by to asi také šlo všechno rozfungovat, ale rozhodně bude po netu méně howtos než pro debian/ubuntu.
Jediné co mi nefunguje, je uspávání mdraidu/disků... to mi zaboha nechce makat.
Ještě mi ke štěstí zbývá domácí síť, zVlanovat a zprovoznit ipv6 (prefix už mám). Když jsem kouknul na provoz, tak přecijen těch zařízení co mají v síti adresu, už mám aktuálně přes 20 (od telefonů po "chytré" televize) a nelíbí se mi jak všechno může všude. Samozřejmě takovéto řešení asi není pro každého, musí to mít člověk jako koníček/práci... Zrovna tak jako automechanik se může doma hrabat ve svém autě.