Problém Androidu je prý v příliš široké možnosti výběru

od win2k sp2 su windows rocksolid. pouzivam ich denne 15h denne a za poslednych 12 rokov mi spadli asi 5x. a to vsetko vinou grafickych ovladacov - nepotrebujem graf vykon, tak kupujem tie najlacnejsie sunty s pasivnym chladenim

Taky GUI widlí moc nemusím, proklikávání x úrovní ve Start menu je na draka.

Ale XPčka zatím byly a jsou z widlí nepřekonaný - relativně málo nároků na železo (zvlášť v porovnání s novějšíma), stabilnější než předchozí verze a lidi už si na to ovládání zvykli. Takže pokud Widle, tak XPčka.

S kompatibilitou je to ve Windows tak, že na Windows 8 není problém běžet většinu aplikací napsanou pro Windows 95; u 32-bitových Win8 klidně aplikaci pro DOSu nebo Windows 3.1. Samozřejmě bez rekompilace. 10 let staré dokumenty MS Office samozřejmě otevřete. U jiných formátů to MS asi těžko bude zaručovat :)

Kdy MS ze dne na den změnil API, formát jejich proprietárních souborů, technologii, user interface? API se prakticky jen rozšiřuje, formáty souborů jsou většinou interní (k manipulaci s nimi používáte API), technologie se od prvních Windows NT rozvíjí ale nemění. User interface samozřejmě prochází vývojem, jako všude.

BTW změny všeho a všude jsou přece specialitou Linuxu. Balíčky jsou určené pro konkrétní verzi konkrétního distra, zvuk se řešil přes OSS a dnes je to ALSA, knihovny přešly z ASCII na UTF-8 mnohdy bez zpětné kompatibility atd.

Zrovna dělám údržbu jednoho staršího projektu a testu jsou dělaný pod M$VS 2005. Nepodařilo se to pod Win7 rozchodit, řve něco o tom, že je potřeba instalovat novější verzi a zkompilovat to nejde...

Před měsícem jsem ppoteboval sáhnout do softu, který je sestavený a otesotvaný pdo IAR EW 2.18. Na Win7 to znamernalo půlden hledání patche nebo podle pravidel měsíc retestování softu po překladu jiným kompilátorem. A měsíc času dvou lidí z manažera nevyrazím...

Dokument z Wordu 2.0 v posledním Wordu taky nepřečteš.

Co se UTF-8 týká, je to nástavba ASCII a na problém se zpětnou kompatibilitou jsem nenarazil. Spíš mám probléy, když přetahuju něco z Widlí a nějaký dobrák ve jméně souboru použil diakritiku, tak se název souboru blbě čte kvůli nějaké pochybné CP-1250 :Q

Takže nelži.

VS2005 samozřejmě běží na Win7. Je potřeba mít aktivovaný .NET Framework 3.5.1 v Programs and Features (tuším v sekci Windows Components), a po instalaci VS nainstalovat Service Pack, případně další aktualizace.

IAR EW podle všeho na Windows 7 funguje. Akorát pánové použili protection system s donglem, který má driver; ten "kupodivu" nefunguje. Jo a jejich instalátor při běhu na Windows 7 nenakopíruje nějaké soubory; na to mají patch. Za špatně napsaný setup Windows fakt nemůžou :). Jestli dovedete tímhle strávit půlden, tak děláte něco špatně.
http://supp.iar.com/Support/?note=87391&from=search+result

Word 2013 samozřejmě umí otevřít dokumenty Wordu 2.0. Ve výchozí konfiguraci je ale tenhle formát, spolu s jinými staršími, z bezpečnostních důvodů zakázaný. Říká se tomu attack surface reduction :)
http://support.microsoft.com/kb/922849

UTF-8 je sice nástavba ASCII, ale na Linuxu se používá UTF-8, UTF-16 a UTF-32. Jejich zavádění před lety způsobilo řadu nekompatibilit.
Pokud máte problémy se jmény souborů, bude to tím, že je Windows ukládají v UTF-16, a vy se je snažíte číst jako ANSI 1250. To je známý problém: snad každý linuxák si nesprávně myslí, že file names jsou v ANSI 1250. Takže použije na klíčenku mount s příslušným parametrem, uloží názvy souborů s diakritikou... a názvy souborů jsou všude jinde nečitelné.

no právě, problém je v instalaci všeho bordelu kolem. Ve Fedoře mám balík GCC, mám tam IDE a make je furt stejný. Nemusím řešit další balíky a service packy a další koniny a hledat, kde to najít. Prostě napíšu sudo yum update gcc a je to...

Ohledně IAR, máme síťovou licenci na serverech a ten půlden byl spíš kvůli shánění všeho kolem... V rámci firmy je to ještě úspěch :(

Na attack surface reduction měli páni programátoři myslet dřív, než začali co tři roky měnit formát dat. S jendím parserem by takový problémy nebyly, zmizly by ty otravný hlášky při ukádání v compatibility mode,...

Nekompatibilita znakových sad byla vždycky jenom kvůli tomu, že si M$ vytvořil vlastní codepages. Při přenosu *ux - *ux není problém, s anglickýma názvama taky ne a jediný, s čím to blbne, jsou widle. Ty už jsem naštěstí odepsal, takže doma v podstatě nikde. A o klíčence nepadlo ani slovo, myslel jsm uložení na NAS a následně zobrazení na telce s DLNA, nebo přenos po SMB :Q

Ve Windows si stáhnete poslední Visual Studio, a je to bez problému. Pokud si chcete instalovat starší VS, je potřeba ho pak aktualizovat (nakonec to při příštím checku udělá i Windows Update). Předpokládám že pokud si budete chtít na poslední Fedoře instalovat 8 let staré GCC a IDE, také to nebude na jeden krok.

Pokud produkt používá drivery, tak lze předpokládat problémy s kompatibilitou mezi verzemi. To ovšem není chyba Windows.

Tři roky? Word 2.0 je z roku 1991 :). Který jiný wordprocessor používá jeden parser 22 let? OpenOffice? Nebo snad WordPerfect? Kdepak.

SMB ve Windows používá UFT-16. Protokol podporuje vyjednání code page, což se může hodit pro prastaré klienty. Pokud je někde problém, není na straně Windows.
MS si vytvořil vlastní code pages celkem logicky. Pro GUI se totiž stávající code pages nehodily. Přebývala semigrafika, a nebyly v nich věci jako typografické uvozovky, trojtečka apod. A odložit vydání produktu ve zbytku světa o 5-10 let jen proto, aby code page prošla standardizací, by bylo dost hloupé.

Některé aplikace interně používají UTF-16 nebo UTF-32, ale to je čistě jejich rozhodnutí, veškeré API je v UTF-8 a soubory se předávají v UTF-8.

UTF-16 se používá pouze na NTFS, FAT používá ty Microsoftem zmršené verze ISO 8859. Navíc se to netýká jen jmen souborů, ale hlavně jejich obsahu.

Qt a GTK podle vás nejsou API? Aha, vy píšete jen s glibc (která mimochodem používá datové typy char a wchar_t, ten první s minimální podporou pro code pages) a x11lib :)
Mimochodem "podporu" Unicode v X11 pěkně ilustruje tohle:
http://www.x.org/releases/X11R7.7/doc/libX11/libX11/libX11.html#Character_Sets_and_Encodings

VFAT používá UTF-16. Koukněte do specifikace, nebo si vytvořte soubor s českým názvem (na Windows, ať není zmršený) a koukněte na direktory entry v hexa editoru.
Ohledně obsahu je to jednoduché: pokud je na začátku textu BOM, je to Unicode. Pokud ne, jde o starý dokument s code page systému.

Qt i GTK používají UTF-16 hlavně kvůli Windows.

glibc používá proměnnou LANG, kde můžete uvést kódování. Pokud jej neuvedete, je UTF-8.

Ty kódování slouží jen pro určité funkce, dnes všechny nejspíš již zastaralé. Ten systém kódování vznikl v roce 1985, sedm let před UTF-8 a osm před Win32. Dnes se v Xlib běžně používá UTF-8.

VFAT se ale týká jen souborů delších než 8.3, ne? Já si ty problémy s kódováním ve FAT pamatuju i z přenosů souborů mezi českými a německými Windows 98, takže to není specifikum Linuxu.

Hmm, zajímavý přístup, kvůli zmršené minulosti zmršit i budoucnost. Linux nemá moc problémů rozlišovat mezi dokumenty v UTF-8 a lokálním ISO 8859, možná by se v Redmontu mohli inspirovat u příkazu file místo psaní vlastní detekce „Bush hid the faсts“. Anebo neměli už na počátku mršit ISO 8859 :-)

Použití UTF-16 v Qt se dá celkem pochopit, protože Windows a Mac tvoří většinu uživatelské základny, UTF-16 je praktičtější pro interní reprezentaci textu, a výsledný kód je na Windows i Macu rychlejší. Bohužel na Linuxu je nutně pomalejší.
GTK používá směsku UTF-32 a Cčkových 8-bitových gcharů.

Proměnná LANG vám pomůže jen v některých scénářích. Například pokud máte FS s názvy v UTF-8, nastavíte LANG na cs_CZ.ISO8859-2 a voláním open() založíte soubor s názvem kódovaným v 8859-2, tak se název souboru nepřevede to UTF-8. Výsledkem je název souboru v 8859-2 umístěný na UTF-8 FS. Taková UTF-8 invalid byte sequence (IBS) je pak velkým problémem pro všechny ostatní aplikace. Nelze ji zobrazit, a není možný ani round trip [IBS]<==>UTF-16 ani [IBS]<==>UTF-32. Přitom takové Qt interně se jmény souborů pracuje v UTF-16.
Podobných případů, kde se LANG ignoruje, najdete jistě sám desítky.

VFAT píše dlouhá jména i pro soubory s krátkým názvem. Windows 98 jely v ANSI code page, i když názvy souborů na FS byly v Unicode.

Ta minulost není nijak zmršená, používání kódových stránek bylo svého času nutností. A jasné rozlišení mezi Unicode a non-Unicode textem není zmršení; naopak je to velmi praktické.
Jakákoliv detekce rozeznávající Unicode od kódových stránek je v principu nespolehlivá, zvláště na krátkých textech. "Bush hid the faсts" je přesně důsledek takového postupu. Nakonec i funkce IsTextUnicode má v SDK poznámku, že detekce není spolehlivá.

MS těžko mohl zmršit 8859. ANSI 1250 byl draft 8859-1 (finální verze totiž ještě neexistovala) s přidanými znaky pro typografické uvozovky a pár dalších znaků potřebných pro práci v GUI. Ostatní MS code pages jsou založeny buď také na draftech 8859, nebo byly vyvinuty nezávisle, protože příslušné 8859-x nebyly ještě ani v tom draftu, a to v někerých případech řadu let. Například 8859-13 je z roku 1998. To měl MS podle vás čekat s uvedením podpory baltských jazyků ve Windows do roku 1998, než se ISO uráčí standardizovat code page, která je stejně pro práci v GUI nevhodná? Další lahůdkou je třeba hebrejská 8859-8, ve které vyjma znaků nutných pro práci v GUI chybí také nikkudim (což je zjednodušeně srovnatelné s absencí diakritiky v českém textu).
Celkem chápu, že by se vám díky použití CPs 8859 na Linuxu líbilo je mít i všude jinde, a že byste ze současné situace rád někoho obvinil. Jenže realita je trochu jinde.

Balíčky nejsou určeny pro konkrétní verzi konkrétního distra, proto v sobě mají uvedeny závislosti. Pokud ty závislosti dokážete splnit, lze používat ty balíčky kdekoliv, kde se používá daný formát balíčků (jsou jen dva běžné formáty, navíc jde mezi nimi celkem dobře převádět), což znamená maximálně přidání dalšího repozitáře. Na mém Kubuntu 13.04 klidně můžu spouštět programy pro Debian Potato.

Dnes je standard PulseAudio. ALSA implementuje plně funkční OSS API a PulseAudio implementuje zvukovku pro ALSA. Není tak problém přes PulseAudio hrát Quake 2, který používá OSS.

UTF-8 (ISO 10646-1) je zpětně kompatibilní s ASCII, to byl také účel jeho vzniku, stejně jako jsou zpětně kompatibilní ISO 8859 sady. Na rozdíl od Unicode funkcí ve Windows.

Ty formáty nejsou jen dva, a instalace balíčků na jinou než určenou verzi distra je o hubu. Kubuntu je odvozené od Debianu, takže to nejspíš dopadne dobře; ale není to žádné pravidlo, které by obecně fungovalo.

Quake lze hrát na instalaci s ALSA? Wow, to jsem nečekal. Někdy se to zjevně i povede.

UTF-8 je s ASCII kompatibilní dost omezeně. Například ASCII algoritmus zalamování řádek vám u azbuky bude produkovat řádky třetinové délky, Cčkové funkce pro hledání znaku jsou nepoužitelné (to bylo "vyřešeno" změnou dokumentace - memchr místo znaku najednou hledá "byte") atd. Navíc to přináší řadu problémů, když neumíte rozeznat třeba file names mezi UTF-8 a ASCII. V Linuxu se navíc inteligentně nepoužívá Byte Order Mark, aby to bylo ještě zábavnější.
K tomu je UTF-8 nevhodné pro interní reprezentaci textu. Díky tomu Qt používá UTF-16 a GTK UTF-32. Aby to bylo zábavnější, například Qt interpretuje každý název souboru na disku v UTF-8; pokud je v ISO code pages, máte problém, protože ho neumí převést do UTF-16. Round trip UTF-8=>UTF-16(32)=>UTF-8 je jednak zbytečnou ztrátou výkonu, a pak není zaručeno, že výchozí UTF-8 string je shodný s výsledným.
Ve Windows je to vyřešeno daleko lépe. Všechno jede v UTF-16, a pokud se volá API v ANSI nebo OEM code page, všechno se do UTF-16 převede. ANSI API je samozřejmě dál podporované - nešly by bez něj spustit aplikace pro Win9x, Win3x, a aplikace psané idioty co od roku 1993 nepostřehli existenci Unicode.

Běžné formáty jsou jenom dva: RPM a Deb.

O hubu je možná instalace programů na jiné Windows, než pro které byly vydány, ale už jsem několikrát instaloval balíčky pro Red Hat na Debianu a o hubu to nebylo, ten převáděcí program upozorňuje na všechny možné problémy, takže jejich řešení bývá celkem jednoduché.

UTF-8 je s ASCII zpětně kompatibilní. Jistě víte, že to neznamená, že to bude s funkcemi napsanými pro ASCII fungovat optimálně. Nakonec aplikace pro Windows 3.11 fungují ve Windows XP taky dost podivně. Rozpoznání jmen souborů mezi ASCII a UTF-8 se díky té zpětné kompatibilitě řeší velmi jednoduše: když to přečtete jako UTF-8, nemůžete udělat chybu ;-)

BOM v UTF-8 nepotřebujete, je vždy big endian. Unicode Consortium nedoporučuje v UTF-8 používat BOM (bohužel zakázat jej už nemůže). Linux se tedy v tomhle chová slušněji než windowsí Notepad, kde IIRC ani nejde BOM vypnout.

Qt i GNOME používají kódovou stránku specifikovanou v LANG, přičemž výchozí je UTF-8. Pokud máte LANG pro UTF-8 a soubory v ISO 8859, máte na svém počítači něco hodně špatně a nefungující převody jmen souborů budou jen maličkost.

UTF-8 slouží hlavně pro přenos dat. Interně si to můžete přeskládat do čeho chcete, podle toho, co potřebujete (IMO nejméně tři čtvrtiny aplikací to ani nijak převádět nepotřebují a pro ten zbytek je UTF-16 pro zpracování textů stejně celkem nevhodné). Převod UTF-8 ↔ UTF-16 i UTF-8 ↔ UTF-32 je celkem triviální a v porovnání s dalším zpracováním textu výkonově zanedbatelný. Pro platný UTF-8 řetězec je zaručeno, že výsledek převodů UTF-8 → UTF-16 → UTF-8 bude totožný s původním textem (s výjimkou BOM, které byste ale neměl používat), i když ve Windows jsem se už setkal s tím, že ve výsledném UTF-8 byly v rozporu s normou surrogate pairs zakódovány jako surrogate pairs a ne jako code pointy.

rpm a deb jsou nejběžnější formáty balíčků, ale zdaleka ne jediné.

UTF-8 je zpětně kompatibilní s ASCII, ale bohužel ne s 8-bitovými znakovými sadami. Rozpoznání jmen souborů se pak řeší opravdu triviálně: zkuste to jako UTF-8; možná to způsobí chybu, a možná se o ní dozvíte až daleko později :)

Minimálně Qt pokud vím LANG ignoruje. Navíc soubor v UTF-8 bez BOM prostě nerozeznáte od nějaké 8859-* code page. Instalací nového distra Linuxu se vám nepřevedou do UTF-8 vaše sobory, natož soubory které dostáváte zvenku :)

Ano, jak sám píšete, round trip UTF8<->UTF16 ani UTF8<->UTF32 není spolehlivý ani u validních sekvencí. Když k tomu přičtete to, že vstup může být klidně v nějaké starší code page, a naprostá většina implementací UTF-8 navíc skousne i řadu nestandardních sekvencí, je v tom pěkný guláš.

Taky jsem psal: jsou jen dva běžné formáty, navíc jde mezi nimi celkem dobře převádět

UTF-8 má velmi dobrou synchronizaci, takže je dost snadné jej na základě pravděpodobnosti rozlišit od ISO 8859. Obzvlášť když víte, že všechny soubory v daném adresáři musí být ve stejném kódování. Na rozdíl od rozlišení UTF-16 a 8-bitových sad, to je totiž dost neproveditelné.

Qt používá LANG .

Zajímavé, že příkaz file nemá problém rozeznat soubory v UTF-8 od souborů v ISO 8859. Že by to bylo tím, že UTF-8 má dost specifické sekvence?

Zajímavé, že v tom guláš na Linuxu nemáme. Na rozdíl od UTF-16 a „Bush hid the faсts“ :-)

Jinak o tabletu jsem neslyšel. Ale stejně se můžu zeptat, proč Samsung uvádí high-endové telefony s Androidem. To jim to na ničem slabším nechodí?

Pak je ovšem otázka, jestli trávit čas implementací stovek nastavovátek (možnost nastavit název ulice přes celý display, dát barvu ulice shodnou s barvou mapy apod.), které stejně nikdo nepoužije, nebo to úsilí věnovat raději tvorbě celkově kvalitnějšího UI, ve kterém se uživatelé nemusí hrabat. U těch navigací je to myslím jasné: počet možností nastavení je dnes výrazně menší.