Bylo oznámeno vydání Fedora Linuxu 44. Ve finální verzi vychází šest oficiálních edic: Fedora Workstation a Fedora KDE Plasma Desktop pro desktopové, Fedora Server pro serverové, Fedora IoT pro internet věcí, Fedora Cloud pro cloudové nasazení a Fedora CoreOS pro ty, kteří preferují neměnné systémy. Vedle nich jsou k dispozici také další atomické desktopy, spiny a laby. Podrobný přehled novinek v samostatných článcích na stránkách
… více »David Malcolm se na blogu vývojářů Red Hatu rozepsal o vybraných novinkách v GCC 16, jež by mělo vyjít v nejbližších dnech. Vypíchnuta jsou vylepšení čitelnosti chybových zpráv v C++, aktualizovaný SARIF (Static Analysis Results Interchange Format) výstup a nová volba experimental-html v HTML výstupu.
Byla vydána verze R14.1.6 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5, Wikipedie). Přehled novinek v poznámkách k vydání, podrobnosti v seznamu změn.
Jon Seager z Canonicalu včera na Ubuntu Community Hubu popsal budoucnost AI v Ubuntu. Dnes upřesnil: AI nástroje budou k dispozici jako Snap balíčky, vždy je může uživatel odinstalovat. Ve výchozím nastavení budou všechny AI nástroje používat lokální AI modely.
Nový ovladač Steam Controller jde do prodeje 4. května. Cena je 99 eur.
Greg Kroah-Hartman začal používat AI asistenta pojmenovaného gkh_clanker_t1000. V commitech se objevuje "Assisted-by: gkh_clanker_t1000". Na social.kernel.org publikoval jeho fotografii. Jedná se o Framework Desktop s AMD Ryzen AI Max a lokální LLM.
Ubuntu 26.10 bude Stonking Stingray (úžasný rejnok).
Webový prohlížeč Dillo (Wikipedie) byl vydán ve verzi 3.3.0. S experimentální podporou FLTK 1.4. S příkazem dilloc pro ovládání prohlížeče z příkazové řádky. Vývoj prohlížeče se přesunul z GitHubu na vlastní doménu dillo-browser.org (Git).
Byl publikován přehled dění a novinek z vývoje Asahi Linuxu, tj. Linuxu pro Apple Silicon. Vývojáři v přehledu vypíchli vylepšenou instalaci, podporu senzoru okolního světla, úsporu energie, opravy Bluetooth nebo zlepšení audia. Vývoj lze podpořit na Open Collective a GitHub Sponsors.
raylib (Wikipedie), tj. multiplatformní open-source knihovna pro vývoj grafických aplikací a her, byla vydána ve verzi 6.0.
To bude nejspíš problém s mixem zašifrovaného a nezašifrovaného obsahu, ne? Např. reklamní bannery stahované do stránky přímo ze serverů reklamních společností se většinou netahají přes HTTPS, i když ke stránce samotné se přistupuje přes šifrovaný kanál. (BTW, ví někdo, jak se to bude chovat, když by nějaký obsah byl také stahovaný přes SSL, ale z jiného serveru s jiným certifikátem vydaným na jiného poskytovatele a podepsaným jinou („důvěryhodnou“) certifikační autoritou?)
Po kliknutí na ikonu zámku vpravo dole na status baru je v okně, které se objeví, důvod popsán. Já mám nastavené různé barvičky u adresního řádku, abych různé režimy snadno a rychle poznal.
Mixování zabezpečeného a nezabezpečeného obsahu je ale samozřejmě dost problém, protože v zobrazené stránce asi není možné rozumně rozlišit, co šifrované bylo a co ne.
Mixování zabezpečeného a nezabezpečeného obsahu je ale samozřejmě dost problém, protože v zobrazené stránce asi není možné rozumně rozlišit, co šifrované bylo a co ne.A taky tohle.
.
Teoreticky by to rozšíření mohlo chránit i proti útoku s přesměrováním na nehttps login formulář.
<ruleset name="AbcLinuxu">
<rule from="^http://(www.)?abclinuxu.cz" to="https://www.abclinuxu.cz"/>
</ruleset>
<ruleset name="Minimarket Beránek">
<rule from="^http://(www.)?minimarketberanek.cz" to="https://www.minimarketberanek.cz:444"/>
</ruleset>
<ruleset name="Kinderporno">
<rule from="^http://(www\.)?kinderporno\.cz" to="https://kinderporno.cz:1443"/>
</ruleset>
<ruleset name="Microsoft">
<rule from="^http://(www\.)?microsoft.com" to="https://www.microsoft.com"/>
</ruleset>
<ruleset name="Nika Chrastava, výrobna lahůdek">
<rule from="^http://(www.)?nikachrastava.cz" to="https://$1.nikachrastava.cz:444"/>
</ruleset>
<ruleset name="Seznam">
<rule from="^http://seznam.cz" to="https://seznam.cz"/>
<rule from="^http://www.seznam.cz" to="https://www.seznam.cz"/>
<rule from="^http://login.szn.cz" to="https://login.szn.cz"/>
<rule from="^http://email.seznam.cz" to="https://email.seznam.cz"/>
<!-- Novinky HTTPS zřejmě neumí -->
<!-- TODO: Rozšířit na další služby Seznamu. Nepoužívám je, takže nemůžu otestovat. -->
</ruleset>
<ruleset name="Česká spořitelna, internetbanking">
<rule from="^http://(www\.)?servis24.cz" to="https://www.servis24.cz"/>
</ruleset>
<ruleset name="Česká spořitelna">
<rule from="^http://(www\.)?csas.cz" to="https://www.csas.cz"/>
</ruleset>
<ruleset name="Datové sránky">
<rule from="^http://(www\.)?datoveschranky\.info" to="https://www.datoveschranky.info"/>
<rule from="^http://(www\.)?mojedatovaschranka.cz" to="https://www.mojedatovaschranka.cz"/>
</ruleset>
(testováno jen velmi zběžně)
Nj, ale jak chces resit (tvym zpusobem) preklad treba takovyho kinderporna?Tohle zrovna se vyřeší přechodem na IPv6
. Horší to bude s weby typu Wikipedie, které mají tu zabezpečenou URL ještě složitější.
Jenže tohle provést není tak jednoduché. Nakonec je to myslím zmíněno i někde na stránce toho rozšíření. Jak automatizované ověřovat, že HTTPS verze webu odpovídá tomu, co by uživatel obdržel přes HTTP? A proč se vlastně párat s načínám HTTPS, když na ten web nejdříve stejně přistoupíte pro kontrolu přes HTTP?
Tiskni
Sdílej: