Vlákno názorů k článku Intel bude otevřenější, důkazem je uvedení Alder Lake od anonym - Nejsem si jistý, zda mi něco neuniká, protože...

  • Článek je starý, nové názory již nelze přidávat.
  • 2. 11. 2021 9:22

    bez přezdívky

    Nejsem si jistý, zda mi něco neuniká, protože nejsem zaměřený na HW, ale trochu mě překvapilo, že v diskuzi nezaznělo nic o Intel Management Engine. Dokud toto, co má plnou moc nad OS, zůstává uzavřené, přijdou mi takovéto řeči o otevřenosti poněkud... prázdné, nebo přinejlepším polovičaté. Samozřejmě věřím, že to všechno pan Gelsinger myslí upřímně a vážně, ale tím spíš stále vidím rozdíl mezi tím, co si přeje vývojář/inženýr a co management.

    Nicméně jinak samozřejmě s jeho názory o otevřenosti a spolupráci souhlasím. Jen mi přijde, že v dnešní době bude otevřené a bude se spolupracovat jen v rámci toho, co konkrétním firmám přijde výhodné, nebo přinejmenším neztrátové. Takový příklad z poněkud jiného soudku vidím třeba v e-mailu: podle mě to už dávno chce moderní náhradu, „e-mail v2“, ale představa, že si dnes sedne několik firem a dohodne se na novém standardu, který by splňoval moderní požadavky, je podle mne naprosto utopická, protože toho bohdá nebude, aby Googlu či třeba Microsoftu unikla příležitost si trh s něčím takovým nechat jen pro sebe. O požadavku, že by výsledek neměl být nabobtnalý bumbrlíček, který by ideálně měl umět „všechno“ ani nemluvě...

  • 2. 11. 2021 10:48

    JSH

    > sedne několik firem

    Což implikuje "design by comitee" se vším co to obnáší. :)

    > O požadavku, že by výsledek neměl být nabobtnalý bumbrlíček, který by ideálně měl umět „všechno“ ani nemluvě...

    Tady je zásadní problém v tom, že různí lidé (a organizace) mají odlišné minimální sady požadavků. A pokud se ten nebumbrlíček email v2 ujme, tak bude spousta lidí požadovat i tu svou nezbytnou funkcionalitu. A výsledkem bude nějaký email v2.1234, který bude dohákovaný nabobtnalý bumbrlíček.

    Nehledě na to, že ten email v2 bude muset být zpětně kompatibilní se starým emailem. :)

  • 2. 11. 2021 11:28

    bez přezdívky

    To, co popisujete, jsou právě ty důvody, proč si myslím, že by to byl dnes problém (resp. podmnožina těch důvodů). Zároveň věřím, že kdyby zde byla vůle hledat kompromis, a ne jen prosazovat tu svou jedinou správnou představu o výsledku, byly by všechny řešitelné.

    A právě proto tvrdím, že ty řeči o otevřenosti a spolupráci jsou sice hezké, ale realitě budou odpovídat jen, když se to bude hodit.

    Trochu podobný příklad vidím v Microsoftu - podle mého osobního názoru nezačal spolupracovat s Linuxovým světem proto, že by vedení najednou začalo rezonovat s myšlenkami otevřeného softwaru, FSF či dokonce Stallmanem. Já věřím tomu, že pochopili, že Linuxový desktop pro ně není hrozba (za mne - bohužel), v serverovém světě jde o silnou konkurenci a tedy spolupráce s Linuxem je pouze prostředek k tomu rozšířit svou sféru vlivu. Podle mne teď nevydávají zdrojáky k vybranému SW z filozofických důvodů, ale protože dospěli k závěru, že je to pro jejich byznysové cíle výhodné.

    A tedy, co se týče Intelu, Gelsingerovi klidně budu věřit, že to myslí upřímně. Ale firmě samotné? Ani náhodou a IME je pro mne důvod jim ani nenechat „benefit of the doubt.“ Pokud mě svými činy přesvědčí o opaku, budu jen rád.

  • 2. 11. 2021 13:47

    JSH

    Vůle hledat kompromisy by tu byla. Krásný příklad by byla třeba ta řada RFCček rozšiřující staré maily. Tam je přece podpora napříč celým odvětvím. :)

    V čem konkrétně by ten mail v2 měl být jiný? Co by to přineslo a za jakou cenu?

  • 2. 11. 2021 14:37

    bez přezdívky

    V čem konkrétně by ten mail v2 měl být jiný?

    Neúplný výčet:

    • Šifrování - aktuálně kdekoliv na cestě mohou data putovat nešifrovaně.
    • Podpora pgp, nebo něčeho podobného. S aktuální situací jsem sice obeznámený jen částečně, ale co vím, není ideální.
    • Nemožnost posílat e-mail z libovolné adresy - je-li server na example.com, může poslat pouze maily z <user>@example.com, ale už nemohu poslat z zeman@vlada.cz. Samozřejmostí je mechanismus pro ověřování (např. každá zpráva je podepsaná klíčem serveru).
    • Lepší řešení příloh. Uznávám, že toto je asi bod, který nejspíš vyvolá hodně výrazné diskuze na téma vhodného řešení. Můj nástřel by byl, že odesílací i přijímací server poskytnou API pro zjištění maximální kapacity a klient tak může hned vědět, kolik může poslat (samozřejmě obecně, ne pro konkrétního příjemce, kvůli skenování adres spammery).
    • Mechanismus pro spolehlivé ověření příjmu zprávy. (Zda něco takového zavést i pro ověření otevření/přečtení zprávy, je otázka.)
    • Jednotné a pořádné řešení vložené grafiky. Když teď pošlu mail a vložím do něj obrázek, podle toho, kdo mi odpoví, někdy je obrázek v citaci funkční, někdy je vložen do přílohy pod nějakým kódem (tipuji, že začátek base64 obsahu souboru), někdy tam není.
    • Sám jsem to neřešil, ale četl jsem, že pro různé klienty je problém validně zobrazit obsah mailu a pro tvůrce je obtížné nastylovat obsah tak, aby vypadal všude stejně. Tohle bude asi taky kontroverzní, ale vzhledem k tomu, jak se aktuálně svět vyvíjí, bylo by IMHO vhodné technické řešení, aby bylo možno mít kontrolu nad vzhledem mailu tak, aby to nebylo komplikované, jako dnes. Vzhledem k tomu, že se dnes CSS často vkládá přímo do HTML mailu, zkopírování jedné části umí kompletně rozhodit celou zprávu. V tento moment používám v Thunderbirdu „vložit bez formátování,“ všechno ostatní je problematické. (Co teprve pro BFU.)
    • Zjednodušit nastavování klientů.

    Tohle jsou problémy, které jsem si teď namátkou vzpomněl, ale dost často na fórech narážím na nejrůznější stížnosti, určitě se najde mnohem více důvodů.

    Co by to přineslo [...]?

    Vyšší bezpečnost, větší pohodlí při používání, možnost přímočařejšího a jednoduššího ověření odesílatele, limity přílohy, které nepřipomínají konec minulého tisíciletí.

    Problém je, mj., naše lidská psychika - jakmile nějaký úkon není dost jednoduchý, prostě jej nebudeme dělat a to v případě mailů znamená bezpečnostní riziko.

    [...] za jakou cenu?

    Nedokážu vyhodnotit.

  • 2. 11. 2021 16:32

    JSH

    Nepřijde vám ten seznam pořadavků trochu nekonzistentní a protichůdný?
    V jednom bodu se bojíte skenování adres spammery a hned potom navrhnete spolehlivé ověření příjmu zprávy. :D

    Nějaké složité stylování je obecně problém, pokud chcete mít univerzální komunikační prostředek. Současný mail se na některých prostředích rozsype, ale jde přečíst. Jakýkoliv nový mail, co by bazíroval na formátování tahle prostředí odřízne úplně.

    Jsem si jistý, že ke svému seznamu požadavků najdete nějaký odpovídající komunikační protokol. Akorát ho moc lidí nepoužívá, protože nemá jiné důležité vlastnosti emailu. A váš email v2 by dopadl úplně stejně.

  • 2. 11. 2021 17:48

    bez přezdívky

    Nepřijde vám ten seznam pořadavků trochu nekonzistentní a protichůdný?

    Jistě. Kdybych si myslel, že všechny (rozumné) požadavky na e-mail by nebyly protichůdné, že by je šly sepsat do jednoduchého, jasného a čistého seznamu, který by více-méně naváděl k jediné implementaci, měl bych o důvod méně si myslet, že by vytvoření a zavedení nové verze byla utopie.

    Už dávno jsem se naučil, že moje idealistická představa o čistých a jasných řešeních v IT je zcestná.

    Je mi naprosto jasné, že a) by nový email musel být založen na kompromisech, b) nejsem vhodná osoba, která by jej měla definovat.

    Jakýkoliv nový mail, co by bazíroval na formátování tahle prostředí odřízne úplně.

    Zrovna to si myslím, že patří mezi ty menší problémy. Protože už samotné zavedení náhražky aktuálního e-mailu by vedlo k podobnému problému, který by se musel nějak řešit.

    Jsem si jistý, že ke svému seznamu požadavků najdete nějaký odpovídající komunikační protokol. Akorát ho moc lidí nepoužívá, protože nemá jiné důležité vlastnosti emailu. A váš email v2 by dopadl úplně stejně.

    To je dost možné. Už v prvním příspěvku jsem podmínil zavedení emailu v2 spoluprací firem - a právě tomu nevěřím, že by se stalo. To, jestli by email v2 byl nový standard, nebo využitý již existující, je vlastně jen „implementační detail.“

    V tento moment si myslím, že by vlastně stačilo, kdyby na něj přešel Google a Microsoft (byť samozřejmě představa, že případný nový standard vytvoří pouze tyto dvě firmy mi nezní moc pozitivně) - jakkoliv se mi nelíbí jejich pozice síly, ta by zajistila dostatečné rozšíření.

    Zároveň si nemyslím, že by „můj seznam požadavků“ byl úplný a že by se dle něj mělo něco měnit či vybírat. Naopak, uvědomuji si, že jsou zde spousty odborníků, kteří by poskytli mnohem přesnější a relevantnější požadavky. Já ten seznam dal tak-nějak dohromady jen na vaši žádost, protože mi není vůbec jasné, zda se s kritikou aktuálního řešení setkáváte, či ne, ale rozhodně jej nepovažuji za reprezentativní. Je to spíš pouze škrábnutí po povrchu.

    * * *

    Prostě to vidím tak, že aktuální stav e-mailu, jakožto primárního způsobu posílání elektronické pošty, je ostudou IT. A to, že se firmy nedokáží domluvit na zlepšení, je ostudou IT managerů.

    To, že aktuální e-maily jsou nedostačující není jen můj osobní názor - až příliš často vidím výtky na téma, že se e-mail používá k potvrzení identity a to nejen v rámci obnovy hesla na nějakém webu, ale i třeba při komunikaci s úřady a tyto výtky zmiňují špatnou bezpečnost a další problémy. Těch výtek je celá řada a jen zlomek z nich se dotýká mě osobně.

    Zavedení nového e-mailu považuji za utopii, takže uznávám, že je potřeba se s aktuálním stavem smířit. A vlastně jsem si na něj už dávno zvykl. To ale neznamená, že bych si myslel, že je ten stav dobrý.

  • 5. 11. 2021 13:27

    BobTheBuilder
    Stříbrný podporovatel

    podle mě to už dávno chce moderní náhradu, „e-mail v2“, ale představa, že si dnes sedne několik firem a dohodne se na novém standardu, který by splňoval moderní požadavky, je podle mne naprosto utopická
    To už tady bylo. CCITT/ITU spáchala X.400 a s tím související adresářové služby X.500. Bylo tam všechno, včetně non-repudiation, takže i datové schránky by byly zbytečné. Umělo to i instant messaging.
    Jenže to byl strašný moloch, centralizovaný, a cílem byla i možnost zpoplatnění (no, ITU, že jo). Akorát to v půlce devadesátek trochu žilo v Německu, byly nějaké SMTP<->X.400 gatewaye a bylo to vidět v hlavičkách mailů z velkých firem, ale po devadesátkách už jsem na to moc nenarážel.
    Opravdu software nejen navržený, ale i implementovaný komisí. Stavěl na OSI modelu, takže napřed bylo nutné implementovat OSI nad TCP/IP (a už máte obludu), pak teprve cokoliv.
    Vedlejším efektem byl (mimo ITU) vznik LDAP (Lightweight Directory Access Protocol je Lightweight právě použitím přímo TCP/IP).