NVIDIA na konci ledna vydala v beta verzi nativního linuxového klienta své cloudové herní služby GeForce NOW. Včera oznámila ukončení beta verze a oficiální podporu Linuxu.
Byla vydána nová verze 3.5.0 nástroje pro inkrementální kopírování souborů rsync (Wikipedie). Přehled oprav a vylepšení v souboru NEWS. Řešeno je 33 zranitelností.
Organizace Apache Software Foundation (ASF) vydala verzi 31 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
Firma IBM uvedla svůj první mikropočítač Personal Computer před 45 lety, v srpnu 1981. Základní konfigurace modelu 5150 za 1 565 tehdejších dolarů obsahovala desktop s Intel 8088 a 16KB RAM, Color Graphics Adapter a klávesnici. Právě klávesnice Model F/XT vybavené kapacitními spínači, vlivné a s převodníkem dodnes použitelné, připomíná sběratelský web Admiral Shark's Keyboards.
Slovensko odhalilo ruské součástky ve dvou testovaných zařízeních na zjišťování přestupků v silničním provozu a označilo je za bezpečnostní riziko. S odvoláním na vyjádření slovenského Národního bezpečnostního úřadu (NBÚ) to včera oznámil ministr vnitra Matúš Šutaj Eštok. Zároveň ohlásil ukončení spolupráce svého úřadu s dodavatelem části uvedeného systému, slovenskou společností Soitron. Opozice, která na problematické kamery upozornila už dříve, vyzvala k odvolání ministra vnitra.
Dle plánu dnes ve 13:00 proběhne veřejný test eDokladů. Jeho cílem je ověřit připravenost aplikace a související infrastruktury na vysokou souběžnou zátěž před podzimními komunálními volbami.
Byla vydána nová verze 3.47 frameworku Flutter (Wikipedie) pro vývoj mobilních, webových i desktopových aplikací a nová verze 3.13 souvisejícího programovacího jazyka Dart (Wikipedie).
Byla vydána nová verze 26.1 linuxové distribuce Manjaro (Wikipedie). Její kódové jméno je Bian-May. Ke stažení je v edicích GNOME, KDE PLASMA a XFCE.
Na akci Made by Google 2026 (YouTube) byla oficiálně představena jedenáctá generace telefonů Pixel s novým čipem Google Tensor G6 a hodinky Pixel Watch 5.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) se spolu s partnery z dalších zemí připojil ke společnému upozornění (Joint Cybersecurity Advisory) týkajícímu se probíhající kybernetické kampaně skupiny LAUNDRY BEAR zaměřené na uživatele e-mailové platformy Zimbra Collaboration Suite (ZCS) nejméně od července 2025. NÚKIB doporučuje organizacím využívajícím Zimbra Collaboration Suite neprodleně ověřit, zda
… více »Jabber rulezzz! Jabber je nejlepší IM! Jabber je svoboda... Ano, tohle všechno je pravda, ale je to málo, je potřeba se dívat do budoucnosti a mít vizi. Nebudu teď psát o profláknutých věcech typu VoIP, ale o tom, co je u Jabberu snad ještě důležitější než technologie - a tím je svoboda a konkurence.
Výhodou Jabberu (kromě funkcí - viz Jabber I - Desatero/2) je to, že nám náš výběr poskytovatele služby neomezuje okruh lidí, s kterými si můžeme psát - bez ohledu na to, jakého poskytovatele si vybrali oni. Což tu ale nemá cenu rozepisovat, už jsem to napsal tady: Jabber II - Svobodný trh.
Když se nám poskytovatel znelíbí (např. málo funkcí, výpadky, cena), založíme si účet jinde, kontakty si přeneseme na nový účet a jede se dál - nepřijdeme o komunikaci s žádným z kamarádů.
Neříkám, že se my, uživatelé Jabberu, máme špatně, naopak, XMPP je super. Ale vždycky je možné udělat další krok dopředu. Prostor pro další zlepšení vidím tady:
Identita: když měníme poskytovatele služby, mění se nám i část JID za zavináčem, podobně jako u e-mailu. Kontakty nám zůstanou (přeneseme si je), ale musíme se navzájem znovu autorizovat. Není to tragédie, jen trochu (málo) práce navíc - ale co když za třicet let budete chtít najít kamaráda ze školy podle jeho JID?
Dostupnost: naše servery běží často v clusterech, takže dostupnost je obvykle velmi vysoká. Přesto může dojít k výpadku jednoho serveru (clusteru, např. domény jabber.cz), potom mají uživatelé dané domény smůlu a jsou odpojení, přestože na světě jsou tisíce jiných jabber serverů, které v pohodě běží. Není to škoda? Nešel by udělat roaming?
Už dnes tu máme jednu možnost: mít vlastní doménu. Domény druhého řádu stojí pár stokorun ročně, domény třetího řádu nestojí prakticky nic, navíc jednu doménu může sdílet více lidí (rodina, skupina přátel). Vlastní doména nemusí nutně znamenat provozování vlastního serveru - lze nastavit virtuální hosting, tzn. nasměrovat svoji doménu na servery poskytovatele, jako to umožňuje např. Google. Toto je celkem snadné a elegantní řešení, pouze vyžaduje spolupráci provozovatele.
Další možností by bylo vygenerování jedinečného ID. Uživatel by si (nezávisle na provozovateli) vygeneroval soukromý a veřejný klíč (které by se pak používaly i k šifrování zpráv). Dostatečně kvalitním hashovacím algoritmem bychom z veřejného klíče vypočítali ID. Uživatel by se potom přihlásil k libovolnému serveru a svoji totožnost by prokázal pomocí elektronického podpisu. Možné nedostatky:
Pokud budeme mít vlastní doménu, není problém ji nasměrovat ji na nějaký fungující server. Ovšem aktualizace DNS záznamů nějakou dobu trvá a je klidně možné, že by se do té doby náš server už podařilo nahodit. Tudíž tudy cesta k HA nevede. Použití jedinečných klíčů / hashů (ID) by vyhovovalo, ale samo o sobě je dost problematické (jedinečnost, centrální registr).
Možná by šlo obě tyto myšlenky skloubit a vytvořit jakéhosi kočkopsa:
Otázkou je, jak ověřit totožnost uživatele při připojování na roamingové servery. Jednou z možností je to, že by se uživatel na roamingovém serveru neověřoval vůbec a jeho totožnost by se zkontrolovala až při začátku komunikace (chatu) pomocí elektronického podpisu (veřejný klíč by byl součástí profilu). Uživatel by mohl podepsat svůj status (jako se to dělá teď) a ">klienti jeho kamarádů by věděli, jestli je to skutečně on a mohli by své uživatele pravdivě informovat jeho o stavu (připojen, nepřipojen...).
Takto bychom dosáhli dostupnosti služby blížící se ke 100% - musela by spadnout většina serverů, aby se někdo nemohl připojit. Řešení by představovalo i nějakou tu režii navíc (zkontrolovat přítomnost uživatele na dalších serverech) - ta by se ale projevila až ve chvíli, kdy je některý ze serverů nedostupný, do té doby by všechno běželo jako teď.
Vedle toho existuje jedno, už dnes fungující, řešení: každý uživatel se zaregistuje na více serverch. Abychom ho neměli v rosteru několikrát, sjednotíme si jeho různá JID do jednoho metakontaktu, jako to umí např. Kopete. Tohle funguje celkem dobře, ale není to správné systémové řešení (máme vlastně kopu bordelu, kterou zakryjeme hezkým GUI, aby se to dalo používat).
Bude dobré začít s větší podporou virtuálního hostingu ze strany provozovatelů serverů (vlastní doména = trvalá identita). Metakontakty v klientech nám zatím přinesou vysokou dostupnost - do doby než bude nějaké lepší systémové řešení. Uživatelé s vlastními doménami nedělají reklamu svým poskytovatelům už ani tím, že mají jejich doménové jméno za zavináčem v JID - otázka proto je, kdo bude provoz serverů financovat. Placené služby? ">Každému uživateli jeho ">server? Reklama mezi zprávami?
Tiskni
Sdílej:
BTW: používáte někdo doménu třetího řádu? Že bysteš měli JID: jméno@moje.jeho.našeMám takle web a mail. Jabber server mám doma na doméně od dyndns.org.
Vraťme se ale k podstatě problému: uživatel se přece nechce spoléhat na to, že jeho kamarád Lojza z vedlejší ulice se o ten server bude hezky starat celý život. Jistým řešením je, že by tu doménu převzal někdo jiný a provozoval ten server, ale to jde jen v případě přátelských vztahů - adminovi taky může hrábnout a doménu prodá člověku, co tam chce provozovat úplně jiné věci než veřejný jabber server.To má jenom dvě řešení – buď nějaké externí adresářové služby, které budou mapovat nějaké uživatelské jméno na aktuální kutečné JabberID. Jenže to pak zase bude problém, že se spoléháte na tuhle službu… A nebo k Jabberu přidat rozšíření umožňující podat zprávu „uživatel se přemístil, jeho nové JabberID je…“ (něco jako HTTP kód
303 See other nebo 551 User not local; please try <forward-path> ze SMTP). Což je varianta jenom pro případ, že Lojza od vedle s údržbou serveru nesekne hned, ale server mu bude umírat postupně.
To má jenom dvě řešení – buď nějaké externí adresářové služby, které budou mapovat nějaké uživatelské jméno na aktuální kutečné JabberID. Jenže to pak zase bude problém, že se spoléháte na tuhle službu…Pak by ale stačilo vyřešit přechody mezi poskytovateli adresářových služeb, nemuselo by se to řešit u každého protokolu zvlášť. Poštovnímu programu by se zadalo cosi jako contacts://jenda@geeks.cz a program by si od adresářové služby vyžádal e-mailovou adresu uživatele jenda (pokud by jich měl víc, tak by nabídl uživateli výběr mezi profily.. pracovní, domácí atd.). Zároveň by se mohl stáhnout i např. jeho veřejný klíč. Jen je potřeba vyřešit, aby všichni neměli přístup ke všem kontaktům (třeba jenom mail ale ne číslo na mobil).
V klientech to není tak zásadně důležitéV klientech je to důležité pro BFU. Stačí pak totiž zadat jen JID (+ heslo) a je hotovo. Bez této podpory by se musela zadávat ještě zvlášť adresa serveru a to už je určitá komplikace.
Z pohledu uživatele by to bylo fajn a možná by to pomohlo i většímu rozšíření, ale jak jsem psal, chápu, že se do toho poskytovatelům moc nechce.
BTW: mám vlastní server i doménu, takže osobně mě to vůbec netrápí, ať si to řeší někdo jiný.
A kteří klienti a servery nepodporují SRV záznam?Možná se už situace změnila, ale ještě nedávno to bylo tak, že ho podporovalo jen velmi málo klientů a serverů.
IMHO klienta si můžete vybrat svobodně a servery mají plnou podporu.U klienta mě to příliš netrápí, protože si mohu adresu nastavit ručně. Je to jen mírná komplikace. U serverů je to mnohem důležitější a netroufal bych si tvrdit, že všechny (aspoň ty nejpoužívanější) mají podporu SRV záznamů.
Prostě systém XMPP je v tomto ohledu stejný jako u SMTP s tím nepodstatným rozdílem, že pro SMTP máme MX a pro XMPP SRV záznam.A s tím nepodstatným rozdílem, že zatímco podpora MX je u SMTP serverů stoprocentní, podpora SRV u XMPP serverů stoprocentní není.


Podle tohoto klíče by většina IMAP serverů nemohla být IMAP servery, protože nezvládá dokonale některou z částí protokolu. Totéž třeba SMTP servery (teď nehovořím o podpoře MX záznamů).
Asi to bude chtít přeci jen přejít na aktuální verzi a nedržet se starého ebuildu, který je v Gentoo…
ICQ gateways mám nastaveno Encoding na Windows-1250. Zkoušel jsem to jen s originálním klientem ICQ jako protistranou a čeština byla vpořádku. Pokud je s jiným klientem na protistraně s češtinou problém, prohlásil bych to za problém toho klienta
jabber.cz mi čeština nefunguje. Ty dva ICQ transporty pro příště vynecháme
, ale tak bezproblémové, jak jsem si myslel, to tedy s češtinou nemám.