To pocitani nakladu neni vzdycky tak jednoznacne. Podivej se treba na HDMI vs DP: i kdyz je HDMI zatizeno licencnimi poplatky, presto je (kdyz pocitame i spotrebni elektroniku) mnohem rozsirenejsi, nez DP.
Treba TV s DisplayPortem asi nenajdes, i kdyz tomu principielne nic nebrani, a DP ma nad HDMI nekolik vyhod. U projektoru ma DP snad 10%, vic ne (alespon ze se uz nake najdou). U zvuku (surround-systemy) DP nema nic. Atd, atd. Jiste, HDMI melo "naskok" uz pri svem vzniku, ale DP je tady taky jiz ~15 let, a krom pocitacu se vlastne nijak neprosadilo. Na druhe strane, HDMI u pocitacu a konzoli preziva prave kvuli moznosti pripojeni na TV...
Na tom pohořelo AMD, že nemůže podporovat plně HDMI ve svých GPU v Linuxu. Protože opensource driver je proti idee DRM, tak to asociace HDMI odmítla schválit. NVidia, Apple a asi i Intel to obchází dalším čipem na desce, který konvertuje DP na HDMI. Tedy je to blackbox oddělený od ovladače, což HDMI konzorciu nevadí.
Skutečné servery samozřejmě žádné grafické výstupy nemají. To, co má nějaké grafické výstupy je jen převlečené PC. Snad se s Oxide Computer a podobnými zase rychle vrátíme do stavu, kdy je možné plně ovládat servery pomocí příkazové řádky ve všech případech, či pomocí API a obojí přes síť.
Grafika do serveru patří jen jako akcelerátor, ne předpoklad pro schopnost jej plně ovládat.
No v HPE, Dellu, Supermicro atd. už ani nejsou schopni své servery kompletně debuggovat (což není výrok z mé hlavy, ale z úst mj. Bryana Cantrilla, který se podílel na vývoji a provozu Joyentu a následně Samsung Cloudu na hardwaru právě od těchto výrobců). Proč by si jinak velcí cloudoví hráči stavěli svoje servery sami, včetně návrhů v Open Compute Project, řešil se coreboot a podobné projekty? Proč by Bryan a další šli a servery, které žádné grafické výstupy nemají vůbec navrhovali a vyráběli?
Je to poměrně jednoduché, cokoliv, co má něco společného s grafikou jsou v dnešní době statisíce až miliony řádků kódu. I sebe jednodušší grafika je další čip a paměť, který má nějakou spotřebu, nějaké náklady na vývoj, nemusí být dostupný a další věc, která se může rozbít. Když máte a používáte video výstup, tak potřebujete i USB na myš a klávesnici. Další ovladače, další řádky kódu, další komponenty a další potenciální problémy a tedy náročné testování.
Ano, taky si rovnou můžete vymyslet virtuální CD/DVD mechaniku a speciální moduly na ovládání úložiště a co já vím co všechno dnes běžná BMC řeší, jen aby admin začátečník byl schopen nainstalovat Windows přímo na železo.
No a potom se divíte, že server startuje tak dlouho... ono se prostě všechen ten software a všechny různé timeouty v mizerně napsaném firmwaru posčítají. Jsou z toho zranitelnosti, dlouhé updaty a obecně otrava. Všechno je to čas, který nevěnujete činnosti firmy, ale jen udržováním molochu, aby firma mohla fungovat.
Zde je trochu něco k tomu, jak bootuje sled v Oxide Racku: https://www.youtube.com/watch?v=ENAMGTOe6NA
Jediny x86 gear ktery je i neni PC a nema video jsou ty routry od PC engines - ALIX / APU, je tam pouze seriova linka by design, coz plne chapu.
Ale u plnotucneho serveru si odpustit lokalni grafiku si nedokazi predstavit, prace skrze iKVM mi nikdy neprisla pohodlna a vhodna treba na ladeni pri sestavovani/instalaci serveru. Max na obcasne servisni zasahy jako nutne zlo.
A pak jsem jeste potkal nektere modely HPe Moonshot modulu jsou prosty video vystupu (napr. ty co maji Atom C2000 cpu), ty co maji xeony s igpu ale maji vyveden DP port. Nevim zda iLO se tam prezentuje s grafikou pak, zkousel jsem si s tim hrat jen jako standalone a bylo srandovni videt bios skrze seriovy port - emulovalo to nejaky textovy rezim, takze napr. i grub menu se objevilo podivne prerenderovano :D
Synology s x64 nemaju GPU a ani graficky vystup (okrem tych, co maju Celeron). Maju seriovu konzolu a maju plny UEFI. Synology s Celeronmi maju GPU, ale nemaju graficky vystup; vedia GPU vyuzit headless, napriklad pre video encoding.
Tiez je ale pravda, ze OOB management neriesia vobec. Reset do defaultu vyzaduje fyzicky pristup a stub, co je v EFI potom stiahne operacny system. Tam sa nehraju na to, aky operacny system chce user pouzit.
Pokud vím, tak např. Oxide Computer má všechno přes API. UEFI ani BIOS tyto stroje vůbec nemají, protože nepoužívají referenční design ani nic od American Megatrends či Aspeedu. Administrátor tedy interaguje s CLI/ TUI/ API, např. takto:
https://docs.oxide.computer/guides/system/initial-rack-setup
Po nastavení racku je už vše přes CLI/ API/ Webové rozhraní, prakticky jako kdyby to byl cloud, až na to, že to vše do puntíku odbavuje ten rack a že má člověk detailní informace k hardwaru.
Veškerý software, který na racku běží je pokud vím open source.
Pokud vím, mainframy jsou poměrně podobné. Ale s nimi jsem nikdy osobně nepracoval.
Jinak sériové konzole, nebo sériové konzole přes IP protokol jsou hodně užitečné, protože se poměrně jednoduše člověk dostane k datům na dálku, aniž by měl nějaké složité KVM. Pokud je management serveru udělaný rozumně, může být skutečně minimální a nemusí obsahovat složité čipy, ovladače na grafiku, USB, ovladače na USB, jen aby šel nastavit. Předávají se data místo pixelů, což je vždy lepší přístup z pohledu náročnosti na údržbu, bezpečnost a i výrobní náklady.
Odkud máte informaci, že to má UEFI/ BIOS či dokonce libvirt?
Podle mých informací (a odkazovaného videa přímo od jednoho z vývojářů) tam nic takového není. Operační systém/ hypervisor Helios je na bázi Illumosu (dříve OpenSolaris) + části bhyve (původně z FreeBSD) + různá rozšíření pro větší bezpečnost, podporu live migrace atd. říkají tomu propolis, kdybyste to chtěl hledat. Storage mají řešený přes ZFS + crucible, který v podstatě data zrcadlí dohromady na 3 nody.
HDMI je jen lehce oprčášené DVI, používá stejné kódování a stejné IO.
Implementačně je velmi jednoduché, a tím i levné (min. do FULL HD 60Hz, tam stačí něco jako 130nm proces).
DP je mnohem, řádově složijejší a potřebuje daleko více prostoru na křemíku, lepší technologii, zároveň již hotových čipů s ním je výrazně méně, a tak se do produktů hůř integruje.
DP je hlavně paketovaný přenos, je to mnohem modernější protokol. Apple to pochopil rychle, nakonec se DP rozšíří i díky alternativním módům a USB typu C.
DP umí mimochodem přepnout a vysílat HDMI signály, takže lze z DP na HDMI použít pasivní redukci. Prý se tím dají obejít různé implementační bugy kolem HDMI např. na dokovacích stanicích.
V DP mel byt kanal ekvivalentni k USB2, ale zadny produkt to neimplementoval. A pak pozdeji uz prislo TypeC, ktery implementuje prave USB + neco navic, treba DP ALT mode.
Jinak CEC ma jakysi ekvivalent v DDC/CI, komunikace je mozna obojim smerem. Typicky se to vyuzivalo na sdeleni orientace monitoru kdyz byl preklapeci, nebo na rizeni podsviceni. Vzniklo to davno pred CEC, coz se samozrejme u HDMI nelibilo a vytvorili si onen placenej CEC.
Šlo. Borec se prostě rozhodl, že 32GiB bude dostatečný po dobu životnosti Windows NT 4.0. Navíc - mělo se jednat o dočasné řešení (na dobu Windows NT 4.0), než někdo změní celé UI toho formátovacího bazmeku. Jenže to se od té doby nestalo, ten krám je pořád stejný i v dnešních Windows 11. Ostatně Windows 11 nejspíš dodnes umí naformátovat 5,25" disketu na 1,2 MB (nezkoušel jsem to, ale můžu, potřebným hardwarem vybaven jsem a možná najdu i desku s FDD řadičem, která dovolí nastavit v BIOSu i 5,25" mechaniku a utáhne po obejití HW limitů Windows 11).
Zkrátka udělal špatné rozhodnutí, které od té doby nikdo nezměnil.
Souhlas, 4M mi připadá jako divné číslo.
Pro dosažení 2 TB by FAT32 musela podporovat clustery o velikosti 512 kB, tzn. 1024 sektorů, což je asi pitomost, když údaj "sectors per cluster" v boot sektoru je 8bitové číslo. Pokud nepřipustím že 0 může znamenat 256, tak mi jako nejvyšší binární násobek vychází 128, což by odpovídalo matné vzpomínce, že nejvyšší velikost clusteru bývala 64 kB...
Přišel by mi logičtější údaj 4 G clusterů, což by dávalo 2 TB i s clusterem o velikosti 512B (= celý jeden sektor), ale tak to zřejmě taky není: Wikipedia tvrdí, že pro číslo následujícího clusteru je ve FAT32 použito pouze 28 bitů z každé 32b buňky. Tzn. k dosažení kapacity 2 TB jsou zapotřebí clustery o velikosti nejméně 8 kB, tzn. i při maximální velikosti oddílu je na výběr.
Obecně: FAT i ve 32b variantě je ideově prostý spojový seznam, kde buňka v alokační tabulce ukazuje na další buňku v alokační tabulce. Díky rezervaci 8 bitů může každá buňka v tabulce FAT32 nést i nějaké další informace.
Velikost filesystému je údajně omezena datovým polem v boot sektoru, které udává celkový počet sektorů FS a má velikost 32 bitů.
Plastová chytristika mi napověděla, že
FAT32 používá 32bitová čísla k identifikaci jednotlivých clusterů, ve skutečnosti jsou plně využity pouze 28 bitů pro adresování clusterů. Zbývající 4 bity jsou rezervovány pro speciální účely, například pro označení konce souboru nebo pro označení chyb.
Maximální počet clusterů je tedy 2^28, což je 268 435 456. Nicméně, kvůli některým implementačním omezením a kvůli zachování kompatibility se staršími systémy a BIOSy Microsoft stanovil praktický limit na počet clusterů v systému FAT32 na 4 177 918.
Moc mi to teda nepomohlo ;). 4177918 je každopádně 2^22 - 16 KiB. Náhodné číslo jako náhodné číslo ;). Proto jsem ve svém příspěvku to číslo nezmiňoval, nepřišlo mi nakonec nijak významné s ohledem na ten limit.
Já si taky myslím, že to omezení není úplná blbost, protože při hledání posledního volného sektoru asi nikdo nechtěl ani aby alokační tabulka zabírala 1/2 tehdejší průměrné paměti, ani číst několik MB z disku, protože to u disků velikosti třeba 400MB nějakou dobu trvalo (na druhou stranu, u toho 400MB disku nebyla alokační tabulka nějak velká)
Jedina urychlovaci struktura je tahle:
0x1EC: Number of the most recently known to be allocated data cluster.
Tj. v pripade vytvareni noveho souboru nemusite FAT tabulku prohledavat od pocatku pokazde, ale jen od tohoto hintu, coz znamena ze pokud je za poslednim zapisem nejake volne misto, tak mate vyhrano, pripadne preskocite par pouzitych clusteru.
Mimo jine to je duvod proc se to rado pak fragmentuje - protoze alokator bere prvni volnej - FS driver typcky nema informaci o tom, jak velky soubor se snazite zapsat.
4M je ono omezeni, ktere pan vytvoril, ne?
Ale samotny FAT32 je omezen pouze tim 28-bit cislem clusteru (coz dava 256M), a kdyz se podivame na wikipedii na tabulku vedle, tak je tam:
Max no. of files 268,173,300 for 32 KB clusters
Coz odpovida idealnimu stavu 1 file per cluster. Se 4M clustery tam 256M souboru neudelate (to umel snad jen ReiserFS ... jako spojovat male soubory do 1 clusteru).
Osobne si myslim ze pocet polozek ve FAT je omezen z duvodu ze se nejspis cela FAT tabulka cachuje v pameti jako jeden celek - takze pro 256Mi*4 to je tak 1GiB, ale pro 4Gi clustery by to znamenalo 16GiB ram :D
Mi to normálně funguje...
$ yt-dlp https://www.youtube.com/watch?v=bikbJPI-7Kg
[youtube] Extracting URL: https://www.youtube.com/watch?v=bikbJPI-7Kg
[youtube] bikbJPI-7Kg: Downloading webpage
[youtube] bikbJPI-7Kg: Downloading ios player API JSON
[youtube] bikbJPI-7Kg: Downloading web creator player API JSON
[youtube] bikbJPI-7Kg: Downloading player 43bc9526
[youtube] bikbJPI-7Kg: Downloading m3u8 information
[info] bikbJPI-7Kg: Downloading 1 format(s): 313+251
[download] Destination: Blame Me: The Windows 11 Disk Formatter [bikbJPI-7Kg].f313.webm
[download] 100% of 995.53MiB in 00:00:18 at 53.51MiB/s
[download] Destination: Blame Me: The Windows 11 Disk Formatter [bikbJPI-7Kg].f251.webm
[download] 100% of 10.94MiB in 00:00:00 at 49.25MiB/s
[Merger] Merging formats into "Blame Me: The Windows 11 Disk Formatter [bikbJPI-7Kg].webm"
Deleting original file Blame Me: The Windows 11 Disk Formatter [bikbJPI-7Kg].f313.webm (pass -k to keep)
Deleting original file Blame Me: The Windows 11 Disk Formatter [bikbJPI-7Kg].f251.webm (pass -k to keep)
yt-dlp https://www.youtube.com/watch?v=bikbJPI-7Kg
[youtube] Extracting URL: https://www.youtube.com/watch?v=bikbJPI-7Kg
[youtube] bikbJPI-7Kg: Downloading webpage
[youtube] bikbJPI-7Kg: Downloading ios player API JSON
[youtube] bikbJPI-7Kg: Downloading web creator player API JSON
ERROR: [youtube] bikbJPI-7Kg: Sign in to confirm you’re not a bot. This helps protect our community. Learn more
Nicméně: trochu jsem do toho dloubnul a vypnul podporu IPv6 na své síti - a v tu ránu to funguje.
Zřejmě dospěl Google/YouTube k rozhodnutí, že kdo používá IPv6, je hacker, pirát nebo robot. ;oD
Co já vím, já to nastavuju od routeru dolů
. Ale počítám, že to pod nějaké datacentrum patřit bude, normálně tu funguje jen čtyřka.
Fakt je, že občas něco stávkuje, třebas Seznam mi občas posílá, že se lezu do pošty z Ameriky, některé šopy na mne vytrvale mluví německy, a podobně - ale ten YouTube do minulého týdne fungoval (to jsem si dělal školení o udržitelnosti., kde bylo video).
Disney odmítá fungovat jen na Windows - a to mne tolik netrápí. ;o)