Hlavní navigace

Názor ke zprávičce Hlasování k OOXML v ČR od LO - Tedy nevím, jestli výrobní zařízení (zřejmě máte na...

  • Aktualita je stará, nové názory již nelze přidávat.
  • 6. 9. 2007 15:17

    LO (neregistrovaný)
    Tedy nevím, jestli výrobní zařízení (zřejmě máte na mysli technologické linky?) generují ODF, DOC, OOXML, nebo jakýkoliv jiný podobný formát. Když už se v průmyslu něco takového používá, tak CSV, případně XML, zcela výjimečně XLS.

    Pokud chcete přeložit 20 let starý program, tak máte především veliký problém. A například dnešní gcc má řadu rozšíření, která jsou použita samozřejmě i v Linux kernelu, a které jiné překladače neumí.

    Monolitický kernel je špatný, jen se daleko snadněji píše. Vývojářům jádra psát nebudu, diskuze už proběhla. Linus k tomu napsal, že mikrokernely mají nepopiratelné výhody, stejně jako nevýhody, a ty kdo chtějí mikrokernel odkázal na MINIX. Windows používají monolitický kernel, konkrétně Windows 9x. Řada NT má modifikovanou mikrokernelovou architekturu. Servery zde běží v kernel mode, což je zásadní pro výkon. Tradiční mikrokernel totiž umře na velké množství kernelmode transitions, což je pomalé. Viz třeba problémy MacOS s multithreadingem. Doplňte si znalosti.

    Oprava poškozeného zavaděče se řeší tak, že vložíte instalační CD/DVD Windows, zabootujete z něj, a řeknete "repair startup environment" (navíc má boot sector zálohu na určeném místě na disku). Jestli místo toho reinstalujete, tak si doplňte pár znalostí o Windows. Pro začátek doporučuji nějaké školení, nebo lépe pár tisíc stran textů Windows Resource Kitu. Podporu Unicode samozřejmě Linux v jádře nemá. U FS se předávané stringy se prostě zapíší na disk jako jména souborů (nově s možností konverze CP). Takže když budete mít systém jedoucí v 8859-2, aplikace budou volat kernel se stringy v 8859-2. Ovšem aplikace psaná v Qt bude posílat stringy vždy v UTF-8 (a jiné aplikace v jiných code pages). Kernel si s tím neláme hlavu, string prostě použije jako file name, nejvýše ho převede. V důsledku toho má řada linuxových systémů názvy na disku ve více kódových stránkách, a nelze rozeznat, co je v Unicode a co ne. Windows naopak zapisují názvy souborů v Unicode UCS-2, a názvy souborů z aplikací jedoucích v 8-bit code pages (ještě takové bohužel existují) se do Unicode překládají. Mimochodem pokud na Linuxu mountujete Windows disky s konverzí UTF8-ANSI1250, děláte to špatně, protože Windows (VFAT i NTFS) ukládají názvy v Unicode.

    Co mám proti CUPS? Zkoušel jste někdy napsat aplikaci, která zobrazuje a tiskne? Ve Windows to funguje asi tak: máme drivery zařízení. Driver má nějaké capabilities typu "umím kreslit čáry", "umím bitmapy", "umím křivky", "umím rastrovat text", "umím čtverce jedné barvy" apod. Takový driver je v principu stejný pro grafickou kartu, tiskárnu, RDP (Remote Desktop), Citrix Metaframe, plotter, nebo cokoliv jiného. Pak máme modul GDI. Ten exportuje funkce typu "kresli text", "kresli křivku" apod.; obecně na vyšší úrovni abstrakce, než drivery. Když aplikace zavolá funkci GDI, GDI jí přeloží natakové funkce driveru, které driver umí. Tedy pokud driver neumí kreslit křivky, tak je vyrastruje do bitmapy, převede na body či úsečky apod. Poud chcete kreslit na obrazovku a tiskárnu, provede to ta samá rutina, jenom jí podstrčíte jiný kontext zařízení (okno, nebo stránku tiskárny). GDI se mimo jiné stará o barevné profily zařízení, takže je v aplikaci vůbec nemusíte řešit, a přesto máte barvy na různých zařízeních shodné (pokud mají zařízení přiřazené správné profily). Co máte na Linuxu? Pomalou příšernost zvanou X11, pro kterou se píše za trest, pomocí které zobrazujete. Různé Xservery mají nejspíš i vlastní drivery (když už nemluvíme o politicky zapřičiněné nutnosti kompilovat(!) drivery). Na tisk máte CUPS, který má samozřejmě úplně jiné API. Podpora ICC profilů nulová, zato musíte používat různá API. Architektura na houby.

    Dokumentace, to je věc. Viděl jste někdy MSDN Library? Plná dokumentace Win32, MFC, .NETu, reference C/C++, VB, C#, J#, VBScriptu, JavaScriptu, ASP, ASP.NET, OLEDB, ADO, ADO.NET, MS SQL Serveru, MS Exchange, a řady dalších věcí. Mimo jiné spousty tutorialů, příkladů, development guides. Chcete nahrávat video z capture karty, a ukládat ho? MSDN. Chcete psát DB aplikaci? MSDN. Chcete psát webové stránky? MSDN. Asi sám víte, že žádný jiný sytém takovou dokumentaci nemá. Navíc MS dodává řadu dalších SDK, například pro DirectX. Gcc+vim jsou pravěk, produktivita je nesrovnatelně nižší. Nehledě na to, že dnes se většina kódu píše v .NETu, kde nehrozí takové průšvihy, jako v C/C++ (if (a=1) ..., strcpy ap). Výsledkem je daleko vyšší produktivita, a kvalitnější kód.

    Ve Windows je funkční konzole, jen s ní většina lidí neumí (viz typicky for /?). Navíc skriptování na unixech je předpotopní záložitost. Zavolej utilitu, parsuj výstup, zavolej s ním utilitu, parsuj výstup. Je to pomalé, utility nelze lokalizovat, mnohdy nelze přidávat funkce. Na Windows máme PowerShell, což je objektové skriptování nad .NETem. Samozřejmě můžete volat utility, když chcete, ale lepší je provést dotaz na objekt. Například dotaz na procesy může být Get-Process w* | Select-Object name,fileversion,productversion,company. Nikoliv volání utility ps, a parsování sloupců. Technicky vzato lze v PowerShellu vytvořit okno, nakreslit do něj tlačítko, a zavěsit na něj událost. Zkuste do z bashe.

    Kde je probém se Services for Unix? Já je mám (nebo jsem měl) na stroji, a celkem fungovaly. Jo o registry jsme tu s kolegy diskutovali. Konfigurace má místo, kde se ukládá, a interface, kterým se mění. Tím interfacem má být vždy GUI, uživatel nemá nikdy lézt přímo do úložiště konfigurace. Proto registry nemají komentáře. Nakonec když si zakládáte účet v KMailu, děláte to ručně v konfiguráku? A když ho měníte, děláte to také v konfiguráku? Asi ani jedno. No a registry mají řadu výhod. Například jsou indexované a tedy rychlé, mají vždy zálohu poslední verze (máte vždy zálohu poslední verze /etc?) atd.

    Samozřejmě záruky typu "určitě nikdy nemůže hrábnout do paměti kam nemá" učinit lze. Přestavte si, že jazyk nemá konstrukce typu pointery, které by vás odkázaly kamkoliv do paměti. A je hotovo. Nebo chcete záruku, že kód nikdy nezavolá konkrétní metodu, případně že objekt nemá reference mimo vlastní instanci? To vše lze zajistit (v .NETu či Javě, nikoliv v C/C++). Samozřejmě se analýza dělá na úrovni Common Intermediate Language, obdoby Java Bytecode. Zároveň to otevírá možnost oddělovat procesy popsaným způsobem (je zaručeno, že zkompilovaný kód nikam nehrábne, protože to bylo ověřeno při kompilaci), a tedy se lze zbavit kernel mode transition, což velmi šetří výkon. I díky tomu lze v .NETu napsat operační systém, viz Microsoft Singularity. Z vzhledem k tomu, že příští verze Windows bude běžet Win32 aplikace v sandboxu, je zjevné, že za pár let budou na trhu Windows s kernelem v .NETu. Kde bude zatím Linux? KDE obšlehne desktopové vyhledávání, a bude mít nové ikony?

    Samozřejmě .NET je ISO standardem od roku 2003 (Common Language Infrastructure a C#), tedy by podle vaší logiky měl být v ODF použit místo Javy .NET. Ovšem ve skutečnosti může existovat více ISO standardů pro danou oblast. A zjevně lze v ISO standardu použít nestandardizovanou technologii namísto odkazu na existující ISO standard.