Řešil jsem to od nesprávného konce. Rozebral jsem firmware, našel v něm sedm bajtů, které za to můžou, doportoval cizí patch do jádra a otestoval ho. Pak jsem spustil jednu nedestruktivní sondu na jiný disk z téže bedny a zjistil, že u něj stačí jeden příkaz. Rozhoduje totiž výrobce disku, ne značka na štítku.

Proč 528 bajtů

Disky z polí od IBM, EMC, NetApp a dalších bývají naformátované na sektor o velikosti 520 nebo 528 bajtů. Je to 512 bajtů dat plus 8 nebo 16 bajtů metadat, ze kterých si řadič pole počítá vlastní kontrolu integrity. Uvnitř pole to dává smysl a stojí to jen kus interní rezervy; kapacita na štítku zůstává celá.

Mimo pole je to problém. Blokové vrstvě Linuxu velikost bloku, která není mocninou dvou, neprojde: blk_validate_block_size() ji odmítne a disk zůstane s nulovou velikostí. Neuvidí ho LVM, ext4, XFS ani ZFS.

Není to chyba jádra a nemá cenu na ni čekat. Celá bloková vrstva počítá s tím, že se offset v bajtech dostane na číslo sektoru posunem. Kdo chce 528bajtový disk používat mimo pole, musí ho buď přeformátovat, nebo přepočítávat sám.

Co jsem zkusil a nefunguje

Tohle je asi nejužitečnější část textu, protože fóra na tuhle otázku odpovídají buď „nejde to“, nebo „zkus sg_format“. Všechno níž jsem zkoušel na živém disku a žádný z těch pokusů disk nepoškodil.

Ty tři nejzajímavější řádky stojí za rozvedení.

Blokovaná je změna, ne formátování. FORMAT UNIT na stávající velikost sektoru projde bez potíží. Jakmile v parametrech stojí jiné číslo než 528, disk vrátí vendor-specific kód ASC 0x26 s ASCQ 0x99. Týmž kódem mimochodem odmítá i pokus přepsat maximální rychlost linky ze 6 na 12 Gb/s. Je to jeden a týž zámek na dvě různé věci.

Crossflash disk poznal a odmítl vědomě. Nahrání pravého podepsaného firmwaru od Seagate skončilo po dvaadvaceti segmentech. Zajímavé je, že standardní varianta obrazu je odmítnutá okamžitě, kdežto SED varianta se dostane dál. Disk tedy typ souboru uznal a padlo to až na kontrole zákaznického stavu, o které mluví produktový manuál Seagate v oddílu o ověřovaném stahování firmwaru: obraz musí odpovídat modelu, revizi a customer status.

TCG vrstva odpovídá, ale nic nedělá. Level 0 Discovery funguje, jen je potřeba správné CDB, protože alokační délka se u něj udává v blocích, ne v bajtech. Disk vrátí Opal SSC 1.00 a hlásí zámky jako podporované a zapnuté. Skutečná session ale nefunguje: SECURITY PROTOCOL IN vrací pokaždé prázdný payload. Rozhodl to jeden test. Poslal jsem na ComID 512 bajtů čistého nesmyslu, samé 0xdeadbeef dokola, a disk odpověděl Good. Neplatný paket musí skončit chybou, takže je disk přijímá a zahazuje.

Na výsledku by to stejně nic nezměnilo. Jiný člověk na fóru Serve The Home zkoušel PSID revert na disku, kde mu sedutil normálně funguje, a hlásí, že sg_format po čerstvém resetu skončí na téže chybě. Reset šifrovacího klíče velikost sektoru neodemyká.

Zámek je v datech, ne v kódu

Když softwarová cesta došla, sáhl jsem po obsahu SPI flash. Porovnáním dumpu ze zamčeného disku s dumpem z pravého disku Seagate se dá najít přesné místo, které o velikosti sektoru rozhoduje. Vyšlo z toho, že zámek není kus kódu, ale pojmenovaný konfigurační záznam v datech, a že jeho kontrolní součet umím dopočítat. Přepsat by se muselo sedm bajtů.

Rozepsal jsem to zvlášť v článku Zámek velikosti sektoru sedí v datovém záznamu. Zápis na hardware jsem neprovedl, chybí mi programátor.

Obchvat v ovladači

Druhá cesta zámek neřeší, jen ho obchází. Ovladač sd může číst a zapisovat celé 528bajtové sektory a hostu ukazovat prvních 512 bajtů z každého. Patch, který to umí, existuje, ale přišel bez autora a cílil na strom jádra, který v upstreamu nikdy nebyl. Doportoval jsem ho na 6.8 a otestoval proti fyzickému disku v QEMU, aniž bych restartoval hostitele. Funguje to včetně křížové validace, cena je 16 bajtů z každého sektoru.

Podrobně v článku Nový kernel jsem vyzkoušel proti fyzickému disku bez restartu serveru.

Sonda, kterou jsem měl spustit jako první

Do tohohle bodu jsem počítal s tím, že za vším stojí firmware od IBM. Pak mi do serveru přibyl další IBM disk, tentokrát 400GB kus, a chtěl jsem vědět, jestli se chová stejně, dřív než na něj pustím čtyřicetiminutový formát.

Existuje na to zkouška, která nic nezničí. MODE SELECT má v bajtu 1 příznak SP, který říká, jestli se má nastavení uložit natrvalo. S vypnutým SP disk parametry jen zkontroluje a zahodí, na medium nesahá:

printf '\x00\x00\x00\x00\x00\x00\x00\x08\x00\x00\x00\x00\x00\x00\x02\x00' > /tmp/ms512.bin
sg_raw -s 16 -i /tmp/ms512.bin /dev/sdX 55 10 00 00 00 00 00 00 10 00

V CDB je 55 MODE SELECT(10) a bajt 0x10 znamená PF zapnuté, SP vypnuté. Šestnáct bajtů parametrů je osmibajtová hlavička a za ní block descriptor s délkou bloku 512. Disk buď řekne, že je to v pořádku, nebo odmítne. Trvá to zlomek vteřiny.

A výsledek byl jiný, než jsem čekal:

Oba disky nesou stejnou značku, stejný prefix v identifikaci a oba pocházejí ze stejného pole. Jeden se přeformátovat dá a druhý ne. Kritérium tedy není IBM, ale výrobce, který ten disk pro IBM postavil, a poznáte ho z prvních tří bajtů adresy SAS.

Fóra na to mají tabulku, podle které jde reformátovat NetApp, EMC, Dell, Toshiba, HPE a Huawei, kdežto „IBM branded“ nejde. Podle mého měření je ta tabulka příliš hrubá. Nejde ta část disků IBM, kterou vyrobil Seagate.

Pak už jen jeden příkaz

U disku, který sondu projde, je zbytek nuda. sg_format --size=512 a čekání. U mě to trvalo 36 minut a postup byl po celou dobu lineární.

Průběh jde číst jedině přes sg_requests --progress, protože během formátu vrací sg_turs i sg_readcap jen „device not ready“ a jádro drží nulovou velikost. Odhad zbývajícího času má smysl dělat až po nějakých pěti minutách běhu: vzorek z prvních 150 vteřin mi vyšel na dvě hodiny, skutečnost byla 42 minut. Rozjezd není lineární, ustálený běh už ano.

Fast format z SBC-4 existuje a starší disk ho přijal, jenže nezachrání den. Bez něj šel formát tempem 2,35 % za minutu, s --ffmt=1 --dcrt 2,82 %. To je zrychlení kolem patnácti procent, ne řádové. Kvůli tomu nemá smysl přerušovat už běžící formát.

Přerušit ho jde mimochodem bezpečně, což jsem si ověřil. Po ukončení procesu a resetu zařízení hlásí disk Medium format corrupted, což vypadá hrozivě, ale je to očekávaný a vratný stav; stačí formát spustit znovu.

Hlavní obava byla, že s metadaty přijdu o tři procenta kapacity. Nepotvrdila se. Disk si po změně délky bloku přepočítal počet logických bloků z fyzické kapacity:

pred:  757 743 288 x 528 B = 400 088 456 064 B
po:    781 422 768 x 512 B = 400 088 457 216 B

Rozdíl 1 152 bajtů, tedy nic. Zápis přes oflag=direct dává 392 MB/s a testy integrity na zarovnaném, nezarovnaném i koncovém offsetu prošly.

Tři cesty a kdy kterou

Pořadí je dané tou sondou. Když projde, jde se cestou první a nic dalšího se neřeší. Když neprojde, přichází na řadu volba mezi tichým ukusováním kapacity a pájkou. A pořád existuje čtvrtá možnost, kterou jsem si dlouho odmítal připustit: nasadit ty disky tam, kde je 528 bajtů nativní hodnota, nebo je prodat někomu, kdo takové pole provozuje. Pro něj to není vada.

Co si z toho beru

Nejlevnější diagnostika patří na začátek, ne na konec. Ta sonda trvá zlomek vteřiny, nic nezničí a rozhoduje o tom, jestli má cenu dělat všechno ostatní. Kdybych ji spustil první den, ušetřil bych si většinu předchozí práce, protože bych rovnou věděl, které disky jsou ztracený případ a které se srovnají do oběda.

Vzniklo to z předpokladu, který jsem si nikdy nezkusil ověřit. Značka na štítku byla IBM, fóra o IBM discích píšou, že nejdou, takže jsem hledal zámek od IBM. Byl to zámek od Seagate a poznalo se to na jiném disku téže značky. Rozborem firmwaru se přitom to rozlišovací kritérium najít nedalo, protože jsem měl dumpy jen z disků od jednoho výrobce.

Co zůstalo nedodělané, přiznávám rovnou. Zamčené disky odemčené nejsou. Vím, kterých sedm bajtů by se mělo přepsat, ale zápis do flash jsem neprovedl. Emulace v jádře běží a prošla křížovou validací, ostrá data na ní ale nemám a mít nebudu, dokud neproběhne dlouhý test s verifikací. A rychlost linky zůstává na 6 Gb/s, protože ten limit sedí ve firmwaru disku a žádná z těch tří cest na něj nedosáhne.

Kód a podklady

Všechno, na čem tenhle text stojí, je ve veřejném repozitáři st1600fm0013-528b-sectors – skripty, zálohy firmwaru i rozbory, které se do článku nevešly.

• reformat-528-512_CZ.md – co u kterého disku prošlo a co ne
• linkrate-6g-analysis_CZ.md – proč disky jedou 6 Gb/s
• tools/ – skripty, kterými jsem firmware rozebíral
• README_CZ.md – celá práce pohromadě

Zdroje

• Serve The Home: How to reformat HDD & SSD to 512B Sector Size – devětadvacet stran zkušeností napříč značkami
• Serve The Home: Changing block size, IBM branded Micron S650DC-800 – tentýž problém na disku od jiného výrobce
• Seagate 1200.2 SAS SSD Product Manual 100773817 Rev. D – oddíl o ověřovaném stahování firmwaru a tabulka formátů
• Mattiwatti/sedutil – fork, který se používá na disky z polí

Jak jsem se do téhle situace dostal a co všechno na ty disky nefunguje, je v článku Velikost sektoru zamkl výrobce disku, ne značka na štítku. Tenhle text je o jednom kroku z něj, o rozboru firmwaru.

Než jsem začal stavět obchvat v ovladači, chtěl jsem vědět, s čím vlastně bojuju. Jestli je ten zámek kus kódu, nebo jen položka v konfiguraci. Vyšlo to druhé, a je to podstatný rozdíl: kód bez podpisového klíče nepřepíšu, kdežto datový záznam s kontrolním součtem, který umím dopočítat, ano.

Tři dumpy a proč jeden nestačí

Disk se sám k obsahu své SPI flash nepustí. Jediná cesta k němu vede přes odpájení paměti a programátor, a to se mi u vlastního kusu zatím nechtělo. Na fóru Serve The Home ale visí ve vlákně o reformátování disků na 512 B tři dumpy, které stačí.

• Uživatel Arslan109 odpájel v září 2025 čip z disku ST1600FM0013 s firmwarem 6214, tedy z přesně toho modelu, který mám v serveru.
• Uživatel leromarinvit koupil o dva měsíce později nejlevnější disk téže rodiny s pravým Seagate firmwarem, dumpnul ho ve verzi 0007, upgradoval na 000A a dumpnul znovu. Obojí ověřil dvojím čtením.

Sám o sobě by mi jeden dump neřekl nic. Nevím, kde v tom binárním balíku o čtyřech megabajtech hledat, a hledat naslepo se nedá. Zajímavý je až rozdíl mezi zamčeným a nezamčeným kusem, a k tomu je potřeba mít oba.

Všechny tři soubory mají shodně 4 194 304 bajtů, tedy plnou kapacitu čipu W25Q32. Využito je z toho kolem desetiny, zbytek je výplň nulami a jedničkami. Prvních dvaatřicet bajtů je u všech tří naprosto stejných, takže formát je týž. Zajímavější je míra podobnosti:

IBM 6214     vs Seagate 000A   ->  89,7 % shodných bajtů
Seagate 0007 vs Seagate 000A   ->  80,0 % shodných bajtů

IBM firmware je tedy Seagate verzi podobnější, než jsou si dvě verze Seagate firmwaru navzájem. Z toho jsem odhadl, že rozdíly nebudou v jádru kódu, ale v konfiguraci. Ukázalo se, že ten odhad seděl.

Nejdřív ověřit, že formátu vůbec rozumím

Nechtěl jsem stavět na dojmu. Existuje oficiální balíček firmwaru od Seagate pro tuhle řadu a v něm soubory LOD, které umí rozebrat parser od skupiny EURECOM S3. Když se obsah LOD najde v dumpu, znamená to, že mapování mezi balíčkem a fyzickou pamětí chápu správně.

Artifact 3  type 0x22   0x9f000 B   Flash address = 0xfa0   <- hlavni kod
Artifact 5  type 0x9026 0xd0028 B   Flash address = 0x30
Artifact 9  type 0x1a   0x180 B     <- podpis (384 B)

Obsah Artifactu 3 se v dumpech opravdu našel, a to na téže adrese:

seagate_000A -> posun 0xe0fcc
ibm_6214     -> posun 0xe0fcc      stejny layout
seagate_0007 -> posun 0x10fcc      starsi verze, jiny layout

Novější Seagate dump a IBM dump mají hlavní kód na stejném místě. Ten starší ne, což je jen připomínka, že layout flash se mezi verzemi firmwaru posouvá.

Konfigurace není zašifrovaná, je to prostě text

Kus, kterého jsem si všiml jako prvního, sedí na adrese 0x0e1140. Je to odpověď na příkaz INQUIRY, uložená tak, jak ji disk pošle na sběrnici:

IBM      9f 00 10 02  "IBM-SSG IBM-SSGSSVJ1P6  6214"  "ZAL...  216214"
Seagate  8b 01 10 02  "SEAGATE ST200FM0133     000A"  "ZAJ..."

Stejná struktura, jiný obsah. To je moment, kdy se hledání změní z luštění na čtení. Kolem té adresy jsou další záznamy a mají pravidelný tvar:

[id:1][len:2][00 00][id:1][len-4:2][namelen:1][jmeno][data]

Klasické TLV, jen s tím zvláštním rysem, že se identifikátor i délka opakují podruhé. Toho jsem nakonec využil při psaní parseru jako kontroly: záznam, kde se druhý výskyt neshoduje s prvním, je špatně zarovnaný a posunu se o bajt dál.

688 bajtů, které Seagate nemá vůbec

Pak už je to jednoduché. Vypsal jsem místa, kde má IBM data a Seagate nepopsanou flash:

0x0e1590 - 0x0e1820   656 B   hlavni blok
0x0e1c70 - 0x0e1c80    16 B
0x0e1f40 - 0x0e1f50    16 B
                      688 B celkem

V tom hlavním bloku jsou čtyři pojmenované záznamy, které v Seagate verzi nejsou:

Jméno AIX mě zarazilo. Je to unixový systém od IBM a v dumpu disku vypadá jako věc z jiného světa. Vysvětlení je nudné a zároveň pěkné: IBM si do konfigurace ukládá, jak se disk má chovat ve svých polích, a pojmenovává si ty záznamy po svých platformách.

Uvnitř záznamu 0xc8 leží block descriptor jako holá data, přesně v tom tvaru, jaký chodí po sběrnici v odpovědi na MODE SENSE:

0e1690  09 41 49 58 20 20 20 20 20 20 00 00 00 08 b4 a8
0e16a0  0a 58 00 00 02 10 ...
        "AIX      "         b4a80a58      000210
                            3030911576    528

Počet logických bloků a délka bloku. Tohle je to místo. Ne kus kódu, který by kontroloval, co po disku chci, ale záznam v datech, ze kterého si firmware při startu bere výchozí geometrii.

Katalog záznamů to potvrzuje

Aby to nebyla náhoda, hledal jsem druhé doložení. Konfigurační blok má index, seznam identifikátorů záznamů, které v něm mají být:

IBM      ... c0 c1 c3 [c4 c7 c8 c9] d1 d2 00     21 polozek
Seagate  ... c0 c1 c3               d1 d2 00     17 polozek

Přesně ta čtyři ID navíc, o která jde. Rozdíl tedy není v tom, že by Seagate ty záznamy měl a nechal je prázdné. Nezná je vůbec.

Sedí i třetí věc. Hlavička bloku začíná magickým řetězcem yqnI a hned za ním je délka:

0x0e1130   79 71 6e 49 | f0 06 | 79 9a | ff 00 a4 00 00 00 06 32    IBM
0x0e1130   79 71 6e 49 | 60 04 | ab 93 | ff 00 90 00 00 00 06 12    Seagate
           magic "yqnI"  delka  soucet
                         1776 B
                         1120 B

Rozdíl obou délek je 656 bajtů, tedy přesně velikost hlavního bloku, který má IBM navíc. Tím jsem si potvrdil, jak se to pole čte, a mimochodem i to, že se při zápisu bude muset přepočítat.

Kontrolní součet: součet slov přes celý blok musí dát nulu

Zbývalo pole 79 9a, respektive ab 93. Že je to kontrolní součet, se dá odhadnout z polohy. Horší je uhodnout algoritmus, a zkoušet CRC naslepo je ztráta času. Našel jsem to jinde: na fóru hddguru někdo před lety rozebíral formát LOD a otiskl tam funkci GETSUMM napsanou v REXXu.

Sečti šestnáctibitová slova v pořadí little endian přes celý blok včetně samotného pole kontrolního součtu. Výsledek musí být nula.

Sedí to všude, kam jsem se podíval:

IBM konfig blok  @0x0e1130, delka 0x06f0  ->  soucet 0x0000  OK
SGA konfig blok  @0x0e1130, delka 0x0460  ->  soucet 0x0000  OK
vsechny LOD hlavicky                      ->  soucet 0x0000  OK

Když je to takhle jednoduché, dá se součet po úpravě dat dopočítat jedním odečtením. Žádná tabulka, žádný polynom.

Patch má sedm bajtů

Zbytek je mechanika. Skript najde magic yqnI, projde záznamy, v tom pojmenovaném AIX přepíše block descriptor a dopočítá součet:

python tools/patch_ibm_lock.py vlastni_dump.bin vystup.bin --mode blocksize --blocks 3125627568

Změní se sedm bajtů:

0x0e1136-0x0e1137   kontrolni soucet  0x9a79 -> 0xad33
0x0e169e-0x0e16a1   pocet bloku       b4a80a58 -> ba47d3b0   (3 125 627 568)
0x0e16a5            velikost sektoru  0x10 -> 0x00           (528 -> 512)

Nový počet bloků není odhad, je to hodnota z tabulky formátů v produktovém manuálu Seagate pro tenhle model. Kapacita zůstává na 1600,32 GB, protože těch 16 bajtů metadat si disk bere z interní rezervy, ne z uživatelského prostoru.

Dump musí být z vlastního disku

Jedna věc, na kterou při čtení fór narazíte pozdě, a mohla by stát disk. Konfigurační blok obsahuje sériové číslo a kalibrační data konkrétního kusu. Nahrát cizí dump na svůj disk znamená přepsat mu identitu identitou někoho jiného, a co udělá kalibrace z jiné NAND, netuším.

Postup je proto takový, že se ten cizí dump použije jedině jako předloha k pochopení formátu:

1. odpájet paměť z vlastního disku (WSON-8, 8 krát 6 mm, u konektoru SAS),
2. vyčíst ji programátorem, a to dvakrát, se srovnáním otisků,
3. pustit patcher na vlastním dumpu,
4. zapsat zpět a ověřit čtením.

Co jsem neudělal

Nezapsal jsem to. Nemám programátor ani horkovzduch a rozebírat kvůli tomu zdravý disk mi zatím za to nestojí. Všechno výše je tedy rozbor a nástroj, ne provedená oprava. Ukázkové výstupy, které mám, vznikly z cizího dumpu a slouží k ověření patcheru, ne k nahrání do disku.

Zůstává i jedna věcná neznámá, kterou se nedá zjistit jinak než zápisem: jestli si firmware konfigurační blok ověřuje ještě něčím kromě toho kontrolního součtu. Podpis by byl konec cesty. Že by tam byl, nic nenaznačuje, ale nenaznačuje ani opak, a to je rozdíl, který se v textu o vlastní práci má napsat rovnou.

Co z toho beru jako přenositelné: u zamčené konfigurace se vyplatí napřed hledat rozdíl proti nezamčenému kusu, ne se hrabat v kódu. Konfigurace bývá uložená čitelně, protože ji firmware musí umět rychle přečíst. A kontrolní součet, který nad ní stojí, se skoro nikdy nedělá složitě.

Kód a podklady

Všechno, na čem tenhle text stojí, je ve veřejném repozitáři st1600fm0013-528b-sectors – skripty, zálohy firmwaru i rozbory, které se do článku nevešly.

• tools/dump_config_block.py – vytáhne konfigurační blok z dumpu
• tools/diff_config_records.py – porovná TLV záznamy dvou disků
• tools/patch_ibm_lock.py – přepíše těch sedm bajtů a dopočítá kontrolní součet
• README_CZ.md – celý postup od dumpu po patch

Zdroje

• Serve The Home, vlákno 4968, strana 28 – dumpy SPI flash a jejich popis od lidí, kteří je pořídili
• hddguru, rozbor formátu LOD – funkce GETSUMM
• eurecom-s3/hdd_firmware_tools – parser LOD souborů
• Seagate 1200.2 SAS SSD Product Manual 100773817 Rev. D – tabulka podporovaných formátů

Někdo takový patch napsal a mně se dostal do ruky. Nedalo se ale poznat, kdo ho psal ani jestli ho někdy někdo přeložil. Tenhle text je o dvou věcech, které z toho vzešly a hodí se i jinde: jak posoudit cizí kernelový patch neznámého původu a jak nový kernel vyzkoušet proti fyzickému disku, aniž bych restartoval stroj, ve kterém ten disk sedí.

Proč jsem tu byl a co dalšího jsem na těch discích zkoušel, popisuju v článku Velikost sektoru zamkl výrobce disku, ne značka na štítku.

Co jsem dostal a co o tom šlo zjistit

Dva soubory. Unified diff proti drivers/scsi/sd.c a drivers/scsi/sd.h, 605 přidaných řádků a 6 odebraných, plus pythoní skript, který ten patch přenáší na jiné verze jádra. Cílová cesta v tom skriptu je patches/kernel/9999-wvg-sd-528-translation.patch, což je konvence Proxmoxu. To byla jediná stopa k prostředí, ze kterého to pochází.

Jinak nic. Patch nemá hlavičku, chybí Signed-off-by, autor, copyright i řádek SPDX. Jeho identifikátory jsem hledal na internetu a nenašel ani jeden, ani v gitu jádra, ani na LKML, ani na GitHubu. Časová razítka v diffu ukazují na únor a duben 2026.

Kód přitom působí kompetentně. Převody dělá přes DIV_ROUND_UP, ne bitovým posunem, což je u 528 nutnost, protože to mocnina dvojky není. Odkládací buffery bere z předalokovaného mempoolu, takže se v cestě I/O nic nealokuje. Má ošetřené chyby a stropy na velikost požadavku i hloubku fronty. A správně nuluje protection_type, protože těch 16 bajtů navíc není ochrana T10 PI, ale metadata diskového pole.

Dobře napsaný kód ale není důkaz, že se ten kód někdy překládal.

Kontext, který v jádře neexistuje

Aplikace na čistou 6.8 skončila takhle:

sd.c   10 ze 13 hunku sedi, 3 selhaly (#1, #9, #10)
sd.h    3 ze 3 hunku sedi

Deset hunků prošlo hlavně proto, že patch toleruje posun. Zajímavé byly ty tři, které neprošly. Hunk 9 očekává v kontextových řádcích tohle:

	if (!scsi_device_online(sdp))
		goto out;

	lim = kmalloc(sizeof(*lim), GFP_KERNEL);
	if (!lim)
		goto out;

A hunk 10 pak sahá na lim->max_dev_sectors, tedy přes ukazatel. Stáhl jsem si originály sd.c pro tagy v6.8 až v6.14 a spočítal výskyty:

Do 6.10 včetně tam žádné queue_limits nejsou vůbec. Od 6.11 už ano, ale jako lokální proměnná na zásobníku, ke které se přistupuje tečkou, ne šipkou, a nikde se nealokuje. Patch tedy cílí na strom, který v upstreamu nikdy nebyl.

Přiložený rebase skript to nezachránil, protože spadl hned na první kontrole:

ERROR: sd_revalidate_disk: expected one function definition, found 0

Dohromady to znamená kód, který nikdy neprošel překladem. Kdyby ho autor zkompiloval, na tenhle rozpor by narazil při prvním pokusu. Není to důkaz, že je patch špatný. Je to důkaz, že je neověřený, a to jsou dvě různé věci.

Doportování na 6.8

Tři místa a tři různé opravy:

Past, na kterou jsem naletěl dvakrát

Skript, který ty tři hunky dopisuje, si musí umět ověřit, že už doběhl. Napsal jsem to takhle:

if "sd_528_effective_max_sectors" in text:
    return "uz aplikovano"

Vypadá to nevinně a je to špatně. Ten symbol totiž do souboru přichází už s hunkem 1, který prošel obyčejným patchem o krok dřív. Kontrola tedy hlásila hotovo i ve chvíli, kdy hunk 10 hotový nebyl, a já pak dlouho hledal, proč se překlad chová, jako by mé úpravy vůbec nebyly v souboru. Napodruhé jsem na to naletěl znovu, protože jsem tu podmínku opravil jinde a tady zapomněl.

Správně se kontroluje symbol, který přijde jedině s tím hunkem, který zrovna aplikuju. U hunku 10 je to emu_cap. Obecné pravidlo z toho je krátké: u skriptovaného patchování musí být příznak „už aplikováno“ vázaný na tu jednu změnu, ne na cokoli, co s ní přišlo do souboru.

Testovat nový kernel na stroji, který se nesmí restartovat

Ovladač sd je v tom systému zabudovaný napevno, ne jako modul, takže ho nejde vyměnit za běhu. A hostitel se restartovat nesměl. To vypadá jako slepá ulička, ale není: fyzický disk se dá do virtuálky pustit celý.

qemu-system-x86_64 -enable-kvm -m 2048 -smp 2 -nographic -no-reboot \
  -kernel /usr/src/k/linux-6.8/arch/x86/boot/bzImage \
  -initrd /tmp/qinitrd.gz \
  -append "console=ttyS0 sd_mod.emulate_512_from_fat_sectors=1" \
  -device virtio-scsi-pci,id=scsi0 \
  -drive file=/dev/sg2,if=none,id=d0,format=raw \
  -device scsi-generic,drive=d0,bus=scsi0.0

Podstatné je scsi-generic. Příkazy SCSI z virtuálky jdou rovnou na fyzické zařízení, takže testovaný ovladač mluví se skutečným diskem, ne s emulací. Hostitelské jádro do toho nemluví a běží dál. Initramfs stačí postavit z busyboxu, není v něm potřeba nic než shell a pár nástrojů.

Tenhle postup se hodí i mimo tenhle případ. Kdykoli potřebujete zkusit ovladač proti konkrétnímu kusu hardwaru na stroji, který nemůžete odstavit, je to nejlevnější cesta.

Výsledky

Nejdřív kontrolní běh s vypnutou emulací, aby bylo vidět, že měřím to, co si myslím:

emulate_512_from_fat_sectors=0
    sda: velikost=0        physical_bs=4224     dd -> 0 records

emulate_512_from_fat_sectors=1
    sd 0:0:0:0: [sda] Attached SCSI disk
    sda: 3030911576 bloku  logical_bs=512  physical_bs=512  ->  1445 GB
    dd -> 1+0 records in/out

Pak zápis a zpětné čtení na třech místech, která se od sebe liší tím, jak padnou do vnitřního dělení:

Otisky sedící samy se sebou ale nedokazují tolik, kolik to vypadá. Kdyby emulace ukládala data soustavně o kus vedle, čtení touž cestou by se s ní zmýlilo stejně. Proto ten poslední krok, který mě na celé práci potěšil nejvíc: data zapsaná ve virtuálce přes emulované 512bajtové zařízení jsem přečetl z hostitele nativně jako 528bajtový sektor.

sg_raw -r 528 -o out.bin /dev/sg2 28 00 00 00 03 e8 00 00 01 00

emulace v QEMU:    3b 0f a4 56 af f2 0e 24 c8 c9 87 4b a2 e2 6f 29
nativne na disku:  3b 0f a4 56 af f2 0e 24 c8 c9 87 4b a2 e2 6f 29
                   25 24 02 a8 c3 21 4d d3 96 c4 7f 4b b9 50 4a 53
metadata[512:528]: same nuly

Bajty jsou fyzicky na správném místě ve správných sektorech a 16 bajtů metadat je vynulovaných. Disk po všech testech hlásí zdraví v pořádku, nula vadných sektorů a velikost bloku beze změny 528 bajtů.

Slepá ulička: shim v userspace

Než jsem se pustil do jádra, zkusil jsem to jednodušeji. Plugin pro nbdkit, který totéž přepočítávání dělá nad síťovým blokovým zařízením, se napíše za odpoledne a nepotřebuje překládat kernel.

První verze běžela 4,7 MB/s. Přepočítávala bajt po bajtu v Pythonu, což byla hloupost, kterou jsem si měl uvědomit dřív, než jsem to spustil. Po přepsání na práci s řezy vyskočila na 118 MB/s. To už je použitelné číslo, jenže nativní přístup k témuž disku dává kolem 390 MB/s, takže by se za pohodlí platilo dvěma třetinami výkonu. Plus vrstva navíc v cestě dat, kterou by bylo potřeba provozovat a hlídat. Zamítl jsem to.

Co to stojí a co jsem neudělal

Cena emulace je 16 bajtů z každého sektoru: 1,55 TB místo 1,60 TB na disk, tedy kolem 388 GB ze všech osmi dohromady.

Co se tím naopak nezmění, je rychlost linku – a stojí za to říct proč, protože se to nabízí jako první nápad. Řadič nabízí 12 Gb/s (maximum_linkrate hlásí 12.0 Gbit), ale disk se domluví na 6 a tam zůstane. Ptal jsem se přímo jeho: stránka 19h/01h „Phy control and discover“ vrací u obou phy v bajtu 33 hodnotu 0xaa, tedy hardwarové maximum 6 Gb/s. Strop nesedí v kabeláži ani v řadiči, ale ve firmwaru disku, a jádro s ním nezmůže nic.

Druhý port by nepomohl taky ne, i když disky jsou dual-port. V SAS se rychlost vyjednává na každé phy zvlášť, takže druhá linka přidá redundanci a součet propustnosti – ne vyšší rychlost jednoho spoje. Rozepsal jsem to zvlášť v rozboru rychlosti linku.

A hlavně: ostrá data na tom zatím nemám a mít nebudu, dokud neproběhne pořádné testování. Testy výše byly krátké a záměrně mířené na hranice dělení, ne na výdrž. Než na tom něco poběží, chce to fio s verifikací přes několik hodin, badblocks -w na celý disk, test se souborovým systémem včetně kontroly po odpojení a odpověď na otázku, co udělá výpadek napájení uprostřed zápisu. Šest set řádků v cestě DMA se neprojeví hláškou, ale tichým poškozením dat.

Emulace navíc zahazuje metadata, ze kterých si diskové pole počítá vlastní kontrolu integrity. Disk pak už pole konzistentní nepřipadá. Pro mě to nevadí, používám ho jako obyčejné blokové zařízení, ale zpátky do pole by ten disk už neměl co dělat.

Kód a podklady

Všechno, na čem tenhle text stojí, je ve veřejném repozitáři st1600fm0013-528b-sectors – skripty, zálohy firmwaru i rozbory, které se do článku nevešly.

• kernel-patch/ORIGIN_CZ.md – odkud patch je a jak jsem si ho ověřil
• kernel-patch/port_to_68.py – doportování na API 6.8
• kernel-patch/RESULTS_CZ.md – výsledky měření
• tools/sector528_shim.py – zamítnutý shim v userspace

Zdroje

• drivers/scsi/sd.c ve v6.8 – strom, proti kterému se patch ověřoval
• QEMU: block drivers – dokumentace k obrazům a průchozím zařízením
• nbdkit(1) – rámec, ve kterém vznikl zamítnutý shim

Pojďme na hlavní body, které mě vcelku šokovaly a upřímně doufám, že to ještě Microsoft pořádně dochytá a vylepší..

1) Ikonky

Je hezké, že se vše ubírá směrem flat designu ale myslím si, že by se to dohromady míchat nemělo, působí to trochu kýčovitě.

2) WinKey + E a Tento počítač

Vcelku mi vadí absence položky Tento počítač v start menu, když už se vrátila nabídka start. A když jsem se naučil využívat kombinaci WinKey + E tak Win10 zavede home složku která podle mě postrádá smysl nebo spíše opět mění zažité standardy a ztěžuje jednoduché postupy.
Ano do home složky si dám např. místní disk ale co například budoucí Flash nebo USB disk? Proč z toho dělat balast a na co dvě home složky? (c:\users\uzivatel vs. Home). Na screenshotu níže, jsem si přidal tento počítač a místní disk právě do Home složky.

Musím opravdu udělat jeden klik navíc?

3) Fullscreen metro aplikace

První šok přišel ve chvíli spuštění metro aplikace, která se spustila v docela nevzhledné podobě v okně. Dle mého názoru to úplně rozbíjí celistvost Metro UI tak jak ji známe z Windows 8.
Po chvilce hledání jsem našel volbu kde přepnout nabídku start na Metro UI z Windows 8 nicméně metro aplikace se tak nezačaly chovat a pořád se spouští v oknech.
Windows 10 sice nabízí možnost přepnutí aplikace do fullscreenu ale přepne pouze jednu aplikaci nikoliv všechny ostatní jako default nastavení, což bych očekával právě v případě přepnutí nastavení nabídky start na Metro UI.

4) Grafické faily

Grafikovi z Microsoftu zřejmě ujela ruka o jeden pixel na X tlačítku na zavření okna. Je to malinko jako pěst na oko 🙂 A ty stíny jako hezké ale decentnější by asi vypadaly daleko lépe.

5) Virtuální plochy

Virtuální plochy jsou v preview verzi opravdu preview,jejich využití je zbytečně složité a nenotorné oproti linuxovému prostředí

GNOME nebo i KDE, kde jsou jasné viditelné náhledy všech ploch přímo na liště a je jasné na které momentálně jste. Zobrazení virtuálních ploch se aktivuje tlačítkem na start liště nebo kombinací kláves WinKey + TAB
Virtuální plochy se mi tedy v tomto případě moc nepodařilo dostat pod kůži jako v případě Linuxu.

6) Metro UI vs. Nabídka start

K tomuhle bodu konkrétně nemám výtku, protože je tu možnost to přepnout. Jen uvádím pár screenů, v případě Metro UI není na první pohled žádná znatelná změna.

Závěr

Jsem mírně rozpačitý a nespokojený s tímto krokem „vpřed“. Nicméně pořád je to preview verze takže tuto recenzi je třeba brát s nadhledem a doufat že tyto nedostatky nezůstanou zapomenuty. Cením si toho, že se počítá s jedním systémem na všechny typy zařízení, nicméně myslím že je ještě dlouhá cesta do finále tak se nechme překvapit 🙂

RadioChatujme.cz vysílá nonstop hudbu do celého světa, ale zejména pro uživatele portálu www.chatujme.cz.

Vysílá i online vstupy mluveného slova zejména ve večerních hodinách, kdy mají možnost posluchači a uživatelé portálu volat své dotazy, vzkazy, náměty, připomínky a rozhovory přímo do vysílání na skype rádia. Skype kontakt rádia si můžete uložit do kontaktů ve svém skype. Kontakt na Skype rádia je radiochatujme.cz

Posluchači a uživatelé mají možnost se podílet na koncepci a programové skladbě rádia tím, že sdělí svoje názory či návrhy. Na základě toho je pak možné uzpůsobit vysílání zájmům většiny.

Podělit se o Vaše názory můžete několika způsoby:

1. Napsat pomocí vzkazníku na portálu www.chatujme.cz
2. Pomocí zprávy na webu rádia www.radiochatujme.cz
3. Zavolat na skype našeho rádia radiochatujme.cz
4. Na facebooku rádia www.facebook.com/radiochatujme.cz

Informace, novinky a co se děje na našem internetovém rádiu najdete na:

1. Webových stránkách rádia www.radiochatujme.cz
2. Na Facebooku rádia www.facebook.com/radiochatujme.cz

Poslouchat RadioChatujme.cz lze několika způsoby:

1. Napsat pomocí vzkazníku na portálu chatujme.cz
2. Pomocí zprávy na webu rádia RadioChatujme.cz
3. Zavolat na skype našeho rádia RadioChatujme.cz
4. Na facebooku rádia Facebook.com/RadioChatujme.cz

Informace, novinky a co se děje na našem internetovém rádiu najdete na:

1. Webových stránkách rádia RadioChatujme.cz
2. Na Facebooku rádia Facebook.com/RadioChatujme.cz

Poslouchat RadioChatujme.cz lze několika způsoby:

1. Rádiová stanice
2.  Z webu RadioChatujme.cz
3. Multimediální přehrávače jako např. Mediaplayer, iTunes, VLC, Winamp atd. pomocí streamu našeho rádia
4.  Naladíte si nás také v internetových rádiích i na mobilních přístrojích.

Pro mobilní telefony a tablety lze stáhnout aplikaci podle platformy Vašeho přístroje např. Android, Apple, WindowsMobile

Řešili jste někdy co vlastně znamenají 3 čísla na konci příkazu uptime?
load average: 0,10, 0,09, 0,11

Tato čísla obecně vyjadřují průměrné zatížení linuxového systému za období 1, 5 a 15 minut a nezahrnují žádné procesy, čekající doby i/o wait na discích nebo síti.
Zjednodušeně se dá říct, že tato čísla zobrazují zatížení, vlivem zatížení CPU procesy, nikoliv tedy jen zatížení přímo CPU. To znamená, že zvyšující se zatížení poukazuje pouze na to, že nějaký proces čeká na dokončení předchozího procesu aby mu mohl být přidělen procesorový čas daného procesoru a přitom procesory nemusí vykazovat vůbec vytížení (například u příkazu htop).
Tento jev je nejčastěji způsoben právě dlouhou čekající dobou na přístup k disku, přístupu k síťovému rozhraní a nebo jsou prostě jen zatíženy procesory.

Load 3.00 u jedno-jádrového procesoru znamená 300% zatížení systému, u dvou-jádrového procesoru lze předpokládat, že toto zatížení v ideálním případě by bylo poloviční tedy 1.50.
Pokud tedy máme číslo zatížení rovno počtu CPU, můžeme předpokládat, že hardware je v tomto okamžiku na hraně své optimální schopnosti odbavovat procesy v obvyklých časech a nenastává tak rapidní zpomalení systému (můžeme pozorovat při velkém swapování na pomalý disk kdy se zvedne i/o wait time). Lze tedy říci, že v tuto chvíli systém využil svých procesorů „naplno“ a efektivně, ale pokud takové zatížení je trvalé chtělo by to zvážit posílení hardwaru případně přerozdělení zátěže mezi více serverů.

S těmito informacemi lze napsat skript, který průměrný load přepočítá na procenta – (LOAD / POČET CPU) * 100. Pro ukázku přikládám funkční php skript pro linux (Ve windows jsem nenašel alternativu průměrného zatížení za časový usek, pouze okamžité zatížení CPU pomocí php rozšíření COM)

$numcores = 8; //Počet jader CPU
$sys_load = sys_getloadavg(); //Nativni PHP funkce pro linux
$percent = ($sys_load[0] / $numcores) * 100; //Prepocet na procenta, vybereme hodnotu za posledni minutu
 
print sprintf("%0.1f",$percent) . "%".PHP_EOL; //Vypis se zaokrouhlenim na 1 desetinne misto

Základní použití:

wget https://raw.github.com/sivel/speedtest-cli/master/speedtest_cli.py
python speedtest-cli.py

Výstup:

Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from JON.CZ s.r.o. (188.75.174.173)...
Selecting best server based on ping...
Hosted by Vodafone CZ (Prague) [41.06 km]: 55.631 ms
Testing download speed........................................
Download: 25.77 Mbit/s
Testing upload speed..................................................
Upload: 34.49 Mbit/s
root@mail:~# python speedtest_cli.py
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from JON.CZ s.r.o. (188.75.174.173)...
Selecting best server based on ping...
Hosted by Vodafone CZ (Prague) [41.06 km]: 52.611 ms
Testing download speed........................................
Download: 25.91 Mbit/s
Testing upload speed..................................................
Upload: 34.49 Mbit/s

Nápověda – použití:

$ speedtest-cli -h
usage: speedtest-cli [-h] [--share] [--simple] [--list] [--server SERVER]
                     [--mini MINI] [--source SOURCE] [--version]
 
Command line interface for testing internet bandwidth using speedtest.net.
--------------------------------------------------------------------------
https://github.com/sivel/speedtest-cli
 
optional arguments:
  -h, --help       show this help message and exit
  --share          Generate and provide a URL to the speedtest.net share
                   results image
  --simple         Suppress verbose output, only show basic information
  --list           Display a list of speedtest.net servers sorted by distance
  --server SERVER  Specify a server ID to test against
  --mini MINI      URL of the Speedtest Mini server
  --source SOURCE  Source IP address to bind to
  --version        Show the version number and exit

Ukázka:

function ping($host, $timeout = 1) {
  /* ICMP ping packet with a pre-calculated checksum */
  $package = "\x08\x00\x7d\x4b\x00\x00\x00\x00PingHost";
  $socket  = socket_create(AF_INET, SOCK_RAW, 1);
  socket_set_option($socket, SOL_SOCKET, SO_RCVTIMEO, array('sec' => $timeout, 'usec' => 0));
  socket_connect($socket, $host, null);
  $ts = microtime(true);
  socket_send($socket, $package, strLen($package), 0);
  if (socket_read($socket, 255)) {
    $result = microtime(true) - $ts;
  } else {
    $result = false;
  }
  socket_close($socket);
  if ($result)
    return round(($result * 1000), 0)." ms".PHP_EOL;;
  else
    return "down".PHP_EOL;
}
 
for ($a = 0;$a < 10000 ;$a++ ) {
  print ping( "seznam.cz" );
}

Začal jsem tedy pátrat po tom co s tím. Nejdříve mě napadl root skrz který odmazat nepotřebné appky a nainstalovat nějaký čistič RAM. Nicméně tablet v základu má asi 1 nebo 2 nestandardní nativní aplikace takže jsem šel dál a začal koumat CWM (ClockworkMod) pro případný reflash jiné ROM. CWM potřebuje ke své instalaci root takže jsem nakonec musel hledat variantu pro instalaci root na Allwinter A13 tablet. Našel jsem „oneclick“ exploit s názvem DooMLoRD_v1_Xperia-2011-ICS-ROOT-emu-busybox-su.zip který vlastně udělal vše za mě. Instalace CWM probíhala stejným způsobem nyní pomocí cwm6028-a13-10part-v2.zip (verze s 10partitions) – návod na výběr počtu partitions – http://forum.xda-developers.com/showthread.php?t=2189640.

Říkal jsem si super jdu nahrát CyanogenMod (download) z původní adresy – http://forum.xda-developers.com/showthread.php?t=2343531 bohužel tento tablet nemá standardní přístup do recovery menu a musí se pouze přes nastartovaný system s povoleným usb debuggingem pomocí tohoto příkazu
echo -e 'boot-recovery\0' > /dev/block/nandf; sync.

Pokračuji tedy nahráním CM10 s GoogleApps a příslušnými ovladači na dotyk v mém případě „zet6221-ts (zet6221 alternative)“. Bohužel po nastartování CM jsem zjistil, že dotyk nefunguje a byl jsem pěkně nahranej, protože debugging v základu byl vypnutý a já neměl tedy žádnou možnost jak nastartovat zpátky do CWM.

Začal jsem tedy hledat dál až jsem narazil na jakési zmínky o programu LiveSuite 1.11 (download), který slouží k přímému nahrávání ROM prostřednictvím servisního režimu tabletu. Pohledal jsem k programu podrobnosti a začal experimentovat. Našel jsem dokonce i moji stock ROM tak jsem zajásal, protože odpadly případné problémy s jinou verzí ROM.
Aplikace se z počátku tvářila „nekamarádsky“, protože na mě vybafla s hláškou ohledně driverů které již byly nainstalovány, později jsem zjistil, že tablet musím do servisního módu uvést ještě před spuštěním aplikace LiveSuit. Našel jsem si tedy pár ROMek na zkoušení a začal jsem experimentovat. Zaměřil bych se na ROM s názvem FaaastJB v2.5 kterou jsem nakonec i nechal v tabletu. Pro reflash bylo třeba si nastudovat ještě zkušenosti jiných, protože aplikace LiveSuit po vybrání příslušné ROM se zdála mrtvá. Řešením je vytáhnout USB kabel počkat pár vteřin poté stisknout Volume + zastrčit USB kabel a při stisknutém Volume + několikrát 5-10x cvaknout tlačítko Power a aplikace vyhodí hlášku s dotazem zda provést úplný reflash s Formátem nebo provést jen update.
Další boj nastal se správnými ovladači, protože jak tomu bylo v případě instalace CM10 tak i u této ROM. Vzhledem k tomu, že ROM FaaastJB je dodávaná obecně pro tablety s procesorem Allwinter A10 nebo A13 tak se (pochopitelně od jiných výrobců tabletů) drivery a použité čipy liší.
Nakonec jsem přišel na to že k ovladači na zet6221 potřebuji ještě driver gslx680. Nevím teď jestli stačil jen gslx680 každopádně při pokusu o ruční import ovladače zet6221 do jádra přes příkaz insmod jsem do kernel logu dostal hlášku o chybějícím ovladači gslx680 (download).

Odkaz na všechny potřebné soubory – http://uloz.to/soubory/luky.rys/android/allwinter-a10-a13/

Error: Could not open keyfile ‚/var/lib/barman/.ssh/authorized_keys‚: Permission denied

Řešení bylo nakonec velice jednoduché (nehledě na to že přes všechny snahy mi řešení trvalo skoro pět hodin) a to vypnout SELinux
Vypnout se dá v souboru /etc/sysconfig/selinux přepnutím hodnoty SELINUX=disabled z původní SELINUX=permissive nebo SELINUX=enforcing.
Můj původní předpoklad byl, že jsou špatná práva na složku nebo přímo soubory, bohužel toto se nepotvrdilo. Poté co jsem zavětřil informaci (při googlování) že by se mohlo jednat o problém s SELinux-em tak jsem našel i toto řešení restorecon -R -v ~/.ssh nicméně při mém štěstí příkaz nevypsal žádný výstup a také nic neudělal respektive nic pozitivního.

Prozatím jsem se s tím že SELinux je už od instalace v systému, setkal pouze u CentOS respektive Fedora-based systémech.
Tímto netvrdím, že by to bylo až takové zlo ale prozatím je to „novinka“ a spoustu lidí odradí první a většinou špatná zkušenost..

Doporučuji přečíst o co se vlastně jedná – SELinux na abclinuxu.cz

Výsledek snad nebudu ani vypisovat – můžete videt na přiloženém screenu níže 😀 .

Při prvním přihlášení se vytvoří účet, který se předvyplní poskytnutými údaji z facebooku a provede Vás nutným zbytkem registrace (doplnění přezdívky dle našich kritérií).
Po vyplnění nové přezdívky a hesla se Vám otevře plný účet Chatujme.cz a nyní máte dvě možnosti při dalším přihlášení.
Přihlásit se přes údaje, které jste vyplnili po prvním přihlášení přes Facebook a to Vaše přezdívka a heslo nebo opět kliknout na tlačítko pro přihlášení pomocí Facebooku a účet se ihned přihlásí.
V případě, že již na chatujme.cz účet máte tak po kliknutí na tlačítko „Přihlásit se pomocí Facebooku“ zvolte možnost „Již mám účet“ a účet se jen propojí. Přičtení smajlíků funguje i v této možnosti spojení s Facebookem.

Jako nevinnou věc jsme si dovolili při registraci přes FB (tedy prvním přihlášení) poslat jednu zprávičku na Vaši zeď ohledně Vaší registrace na Chatujme.
Zprávičku můžete zakázat při povolování přístupu, ale při jejím povolení získáte od nás bonus v podobě dalších deseti volných pozic pro smajlíky (takže z původních třiceti máte k dispozici 40 volných pozic pro Vaše oblíbené smajlíky) a zároveň pomůžete Chatujme v rozletu tím, že se o nás dozvědí i Vaši přátelé.
Po propojení můžete používat obojí způsob přihlašování. A to standardní pomocí vašeho nicku a hesla nebo prostě jednoduše kliknutím na tlačítko „Přihlásit se pomocí Facebooku“

Věříme, že vás tato vymoženost potěší a usnadní přístup na náš portál.

Řešil jsem to, že se mi nechce tahat přes půl místnosti kabel k hi-fi věži.
Teď mám mobil u věže, kde je puštěný SoundWire, a mám „WiFi Speaker“.
SoundWire chodí dle očekávání, mají i dobře vypadající neotravnou aplikaci (Server aplikaci) pro různé platformy – http://georgielabs.net/.
Pochopitelně se ve free verzi sem tam občas objeví hlasová hláška „soundwire free version“ a některá speciálnější nastavení jsou pouze v placené verzi.
Free verze splňuje vše, co jsem od toho očekával.

Aplikace „Kontrola Internetu“ (kontrolanet.pl) je napsaná v jazyce Perl na operačním systému Linux Ubuntu 12.04 LTS.
Kdo by měl zájem o tento program, nechte komentář zde pod příspěvkem!