V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
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.
Tímto jsem si založil blog!
Tento článek je původně určen pro školní časopis. Pokud v něm najdete jakékoli nesrovnalosti, dejte mi, prosím, vědět v diskuzi. Děkuji.
Na toto téma se mezi 'pokročilými uživateli' debatovalo už mnohokrát. Taková debata většinou konči povzdechem nad neznalostmi uživatelů začátečníků (tj všech ostatních), nebo nad neexistencí lepší alternativy rozesílání dat.
Nejspíše proto, že je to mnohdy jediný jim známý způsob; typický uživatel internetu zná tak akorát web a e-mail a někteří mezi nimi dokonce nerozlišují (tomu napomohla i existence web-mailu). Dalším důvodem je ohromná pohodlnost tohoto způsobu - soubor skončí adresátovi přímo pod nosem v jeho mailové schránce. Zdálo by se, že s nástupem širokopásmových internetových přípojek, toho web-mailu a gigabajtových schránek padla hlavní nevýhoda – že zvětšení souboru v příloze asi o 1/3 v důsledku kódování příloh do Base64 již nehraje žádnou roli, jenže spousta uživatelů je připojena asymetricky (tedy odesílání po uživatelově lince probíhá několikrát pomaleji, než stahování), a proto se odesílání takového nabobtnalého (neboť base64) souboru může protáhnout. Tento neduh sice řeší web-maily, které base64 při přenosu přílohy k sobě na server nepoužívají, jenže další velice podstatná nevýhoda, totiž že v případě přerušení přenosu jej není možné obnovit, ta zůstává. Představte si. že se vám odesílání řekněme 24MB souboru přeruší na 99 procentech a vy musíte začít odznova.
Protože e-mail jednoduše nebyl navržen k transportu souborů. Tato funkce byla implementována až následně* a neschopnost protokolu SMTP (Simple Mail Transfer Protokol) přenášet něco jiného než text** byla vyřešena překódováním příloh (třeba přiložených obrázků) do textu. Znáte pořekadlo, že jeden obrázek vydá za tisíc slov?
* - v nejnovějším znění v RFC 2047 z roku 1996. Pokud se nudíte, zavítejte na http://www.ietf.org/rfc/
** - RFC 20: ASCI – formát pro výměnu informací v rámci počítačových sítí - z roku 1969. Dýchla na nás historie.
Hlavně z toho důvodu, že 'jejich strojový park' (v některých případech ani jeho programové vybavení, například e-mailový server, který pro každého adresáta zařadí do fronty novou kopii mailu, není příliš vhodný k odeslání 'řeťězáku') nebyl dimenzován na takovou zátěž, jakou představuje typická uživatelská korespondence – řetězové dopisy, vtipná videa o biatlonistech, powerpointové prezentace o tchyních („topím tchyni v kyselině, ona ještě, mrcha, žije...“) nebo koťatech všech tvarů a barev. Hodně (amerických i evropsko-unijních) společností se také potýká s problémem zákonné archivace e-mailů, když jim drahocenné místo zabírají švédští biatlonisté střílející finské soupeře.
Ani samotný proces odeslání takového maxi mailu není bez problémů. Asi před dvěma roky se podařilo úředníkům anglického ministerstva obrany přetížit síťovou infrastrukturu masovým šířením humorného videa, které natočili britští vojáci v Iráku. Každému byrokratovi bylo samozřejmě, vinou lavinovitého rozesílání, doručeno několikrát, což systém neustál.
Pokud využíváte služeb některého freemailového portálu (Seznam, Google, Centrum...), nebude mít vaše extrémně přílohové mailování nejspíš žádné následky – provozovatelé těchto služeb s tím počítají a mohou si takové uživatele dovolit. Pokud tedy nezahltíte adresátovi schránku, můžete mailovat do aleluja. Samozřejmě v případě, že se snažíte o systémové a elegantní řešení, měli byste zavítat ke službám jako je e-disk (www.edisk.cz), nebo YouTube (www.youtube.com) v případě videa. V případě velkého množství adresátů, nebo záměru rozšířit soubor mezi opravdu velkou skupinu uživatelů je také možné využít služeb nějaké P2P sítě. Poslední zmiňované řešení má oproti službám typu e-disk výhodu v rozptýlení celkového objemu přenesených dat mezi větší množství počítačů, zatímco u e-disku, a jemu podobných, si všechno oddře poskytovatel té služby (což vám samozřejmě nemusí vadit.)
A ještě k firmám – mnohé problém řeší úpravou mailu na serveru, který přílohy ze zprávy vypreparuje, dekóduje z base64 a do e-mailu uloží adresu, na které si je může příjemce mailu v následujících sedmi dnech stáhnout.
Nejprve se zaměřme na ASCII. Jedná se o kódování standardizované v RFC 20. Pro každý znak se použije osm bitů, samotné kódování je však sedmibitové a nejvyšší bit (co ve dvojkovém rozvoji toho osmibitového čísla určuje přítomnost /u ASCII vždy nepřítomnost / členu 1*128) je jen vycpávka a je vždy nulový. Tím pádem je zde místo jen pro 127 písmen:
písmena, číslice, jiné znaky (závorky, matematické znaky (+-*/%½¼ ...), interpunkční znaménka (,.:; … (ano, pro ležatou trojtečku existuje zvláštní znak))
speciální znaky (@$~ ...)) a řídící (netisknutelné) kódy, které byly původně určeny pro řízení periferních zařízení (např. tiskárny nebo dálnopisu)).
Pro další jazyky byla vytvořena rozšíření, která definují dalších 128 znaků (písmena s diakritikou a tak) při nejvyšším bitu nastaveném na jedničku. O standardizaci v této oblasti se zasadila ISO, ale její kódování, jako třeba ISO 8859-2 pro češtinu muselo o své místo na slunci bojovat s výplody velkých IT firem, které cítily potřebu vyvinout si kódování vlastní a jinými regionálními kódováními. V naší malé zemi se víceméně používala tato vzájemně nekompatibilní kódování češtiny:
Windows-1250, ISO 8859-2, CP852 (Latin2), x-mac-ce od Apple, jako ČSN norma schválené KOI-8 a kód bratří Kamenických.
Neudržitelnost zatím popsaného stavu je nabíledni. Proto nepřekvapí, že (již ke konci osmdesátých let minulého století) se objevily snahy o sjednocení znakových sad do jedné univerzální. Sjednocující sady vzniky hned dvě (Unicode, UCS - Universal Character Set), naštěstí jsou (a až na váhavé začátky vždy byly) vzájemně kompatibilní, jen Unicode navíc oproti UCS definuje i třídící a řadící postupy pro textové řetězce v různých jazycích a podporuje i zprava doleva psaný text (tj. arabštinu a jí podobné jazyky). A co že Unicode obsahuje? Snad všechny symboly všech jazyků na Zemi (i japonštiny či čínštiny), fonetické symboly a vědecké znaky. Unicode má samozřejmě své nevýhody, z nichž nejvýznamnější je při použití čistého Unicode (tím je myšleno kódování UTF-32) zčtyřnásobení celkové délky textu. Tento problém však řeší kódování s proměnnou šířkou (velikostí v bitech) znaku. A pojďme od specifikace k nejužívanější implementaci (v tomto případě jsou implementacemi další specifikace konkrétních kódování). Například i tyto Křenoviny jsou psány povětšinou v:
UTF-8 vzniklo jako systémové kódování pro experimentální operační systém Plan 9 from Bell Labs (název je inspirovaný nízkorozpočtovým filmem Plan 9 from Outer Space) a je standardizováno v RFC 3629 z roku 2003. V této definici je maximální délka znaku stanovena jako 4 bajty. Zdálo by se, že v oproti UTF-32 jsme si, co se týče zvětšení textu, oproti osmibitovému kódování moc nepomohli. Ale vězte, že se zde používá proměnná šířka znaku, že čeština má všechny svoje háčkované, kroužkované a čárkované znaky dvoubytové, a že zbývající česká písmena jsou uložena stejně jako v ASCII (páč kompatibilita, bude to ještě zmíněno níže), tedy mírný nárůst velikosti textu (o byte za každé písmeno s diakritikou) za pohodlí, které nám celosvětově použitelné kódování přináší, rozhodně stojí.
A jakže se pozná, kolik písmen znak vlastně zabírá? Kde končí jeden a začíná druhý? Ve dvojkovém zápisu je celkový počet bytů pro znak shodný s počtem bitů od začátku prvního bytu znaku po první nulový bit. Dalším vodítkem je, že první bajt znaku na rozdíl od druhého, třetího a čtvrtého nikdy nezačíná na 10, zatímco ty další v pořadí takto začínají vždy. Přehledně v tabulce (písmenko 'v' vyjadřuje libovolný bit; 'v' proto, že má ve většině fontů stejnou šířku jako číslice a já tak nemusím používat monospaceový font; bity označené v tabulce 'v' opravdu kodují znak, ostatní jsou jakoby řídící):
celkem bytů tvořících znak bitů kódujících znak posloupnost bytů ve dvojkové soustavě 1 7 0vvvvvvv 2 11 110vvvvv 10vvvvvv 3 16 1110vvvv 10vvvvvv 10vvvvvv 4 21 11110vvv 10vvvvvv 10vvvvvv 10vvvvvv
UTF-8 tedy může kódovat až 10FFFF (hexadecimálně) znaků (tj. 1114111). Další zajímavostí je, že pokud v našem textu použijeme jen jednobitové znaky, bude text vypadat úplně stejně jak v ASCII, tak v UTF-8, což je prvek zpětné kompatibility.
Jak možná z textu vyplynulo, jde o metodu na převod jakéhokoli souboru do textu, který je pomocí SMTP protokolu jednoduše transportovatelný (tím je myšlen čistý text, tedy binární 'textové' dokumenty MS Wordu musí být též převedeny.) Princip kódování je vysvětlen už názvem (základ64): data souboru se rozdělí po šesti bitech a každá šestice se jednoduše vyjádří v 64kové soustavě pomocí tisknutelných znaků ASCII. Desítkové hodnotě 1 odpovídá A, dvojce B, padesáti malé ypsilon... Proč zrovna 64kové? Protože v ASCII tabulce máme 64 tisknutelných znaků (tedy, máme jich o něco víc, ale snažit se je využít všechny by bylo komplikované, nehospodárné, a nebo obojí - kvůli těm několika písmenkům přece nebudeme používat hned 128-kouvou (2^7) soustavu). Pokud není možné soubor do oněch šestic rozdělit bezezbytku, nastává čachrování s rovnítky, ale popis tohoto by jen zbytečně zdržoval, užitečnější je zamyslet se, co způsobuje ono třetinové (oproti původní, binární podobě) nabobtnání dat, která jsou takto zakódována. Pokud máte zrovna volnou chvilku /asi ano, když čtete Křenoviny/, můžete si nad tím popřemýšlet, pro nás ostatní je tu stručné vysvětlení: - každý znak ve starém ASCII (neUnicode) kódování zabírá osm bitů - z binárního souboru bereme data po šesti bitech a každou šestici zakódujeme jako znak (jako osmibytový znak), tedy ke každé šestici přidáme dvoubitovou 'omáčku' zlomek 2/6 se vykrátí na... 1/3 tedy omáčka bude tvořit třetinu souboru.
EOF
Tiskni
Sdílej:
Znaky jsou sice sedmibitové, jenže každý má ještě vycpávkový nulový bit na začátku, aby se s tím dobře pracovalonikoliv, to si pleteš kódování a jeho representaci ("encoding form" vs. "encoding scheme") ... to už bys rovnou mohl říci, že na 64bit procesoru je ASCII 64bitové kódování, protože má na začátku 57 vycpávkových nulových bitů ...