GIT a Windows (diskuse)

[chrono]

Díky debilnímu platformě závislému buildsystému (čti autotools) se o to ani nemá cenu pokoušet

Odporúčaný spôsob zostavovania je použiť priamo Makefile (na začiatku toho súboru sú napísané premenné prostredia, ktoré ovplyvňujú samotnú kompiláciu).

[chrono]

A ešte som zabudol napísať, že všetky testy (je ich viac ako 6000) fungujú aj na 64 bitovej platforme; teda minimálne na x86_64 architektúre.

[Jardík]

I ve Windows?

[Michal Fecko]

Ked mas Windows 7 J64E (Jardik 64 Edition) tak aj vo Windows ...

[Radek Hladik]

Tenhle zápisek je taky pěkná šmejďárna.

Osobně nechápu tuhletu pözu. Pokud git narazí na omezení 32bit architektury, tak takový projekt bych nechtěl snad ani překládat.Ale matně tuším, že autor zápisku musí mít 64bitový i vzduch, takže víc už neříkám. Howgh. Domluvil jsem.

[Jardík]

Pokud git narazí na omezení 32bit architektury

To asi nebude důvod ... Jinak čtení mých zápisků je jen vaše rozhodnutí a pokud budete chtít, tak je číst nemusíte, nikdo vás nenutí.

[Radek Hladik]

Já vím, že to není ten důvud (a předpokládám, že to z mého příspěvku vyplývá). S (ne)čtením příspěvku, to je opravdu čistě a pouze moje chyba, nechal jsem se zlákat titulkem a neověřil si autora...

[__dark__]

Toto je naprostý nesmysl, tady nejde o žádné omezení 32bit architektury, ale o připravení ekosystému pro knihovny/aplikace, které jsou 64bit only. Současný stav je jen přechodný a budoucnost desktopů a serverů patří právě 64bitové architektuře.

To, o čem mluví jardík (přetypování ukazatele na long, nebo chování se k typu long, jako by měl tento typ stejnou velikost jako ukazatel) je velmi častá chyba vývojářů, co píšou hlavně pro Linux. Není to tak dávno, co tento nesmyslný předpoklad přidali do knihovny cairo.

[Martin Mareš]

přetypování ukazatele na long, nebo chování se k typu long, jako by měl tento typ stejnou velikost jako ukazatel

On Git něco takového někde dělá?

P.S.: Neplatí to ani na Linuxu.

[michich]

P.S.: Neplatí to ani na Linuxu.

Kdy to na Linuxu neplatí? Na nějaké konkrétní architektuře?

[__dark__]

Můžeš sem napsat, kdy to na Linuxu neplatí? Pokud vím, tak LLP64 model používá jen Windows, všechny ostatní OS používají LP64/ILP64 model.

[xvasek]

Současný stav je jen přechodný a budoucnost desktopů a serverů patří právě 64bitové architektuře.

...a na kdy se tak přibližně plánuje odstranění 32bit userlandu ve Windows a v Linuxu? Jestli to bude už pozítří, tak bych si měl zítra vzít volno.

[Radek Hladik]

...a na kdy se tak přibližně plánuje odstranění 32bit userlandu ve Windows a v Linuxu? Jestli to bude už pozítří, tak bych si měl zítra vzít volno.

-

U Microsoftu to záleží na tom, kdy se nějaký jejich manažer ráno vzbudí a uvědomí si, že se ty Windows už tak moc neprodávají a že by to chtělo zase nějakou incentivečku

[Ruža Becelin]

...a s nadsenim v tvari to sdeli na porade, kde dostane na budku, protoze ciste 64-bit Windows budou neprodejne. To by k tomu museli pribalovat 32-bit verzi zdarma...

[Radek Hladik]

Neprodejne? To at si vyresi hosi z marketingu

[Michal Fecko]

WOW^64

[Jardík]

Chalpcí, čistě 64bit Windows bez 32bit šmejďáren už existují - Windows Server 2008 R2 - při instalaci máte možnost neinstalovat WOW64. Už aby ta volba byla i pro desktopové verze, ale jak znám MS, tak tu verzi nějak zmrzačí, kvůli vlivům třetích stran, jako to udělal s Wordem 2010 - úmyslně ho zmrzačil chybějícím editorem rovnic.

[xvasek]

při instalaci máte možnost neinstalovat WOW64.

"A komu tím prospějete, co?"

[AsciiWolf]

Windows Server 2008 R2 - při instalaci máte možnost neinstalovat WOW64..

To je blbost, žádná taková možnost tam není.

[Jardík]

Já to neinstaloval, tak se omlouvám za špatné informace, tu např. píšou, že je to volitelné, tak jsem myslel, že už rovnou při instalaci.

[SPM]

Vážně? To by mě pak zajímalo, čím ta sr*čka zaplácala těch 8GB místa na disku, když to ani neumí emulovat 32bit šmejďárny :))

[__dark__]

Moc dobře víš, že čistě 64bitová linuxová instalace není problém. Ve Windows je problém trochu komplikovanější, protože soft je většinou jen jako binárka, takže odstranění 32bitového režimu asi nebude tak brzo. Ale požád nechápu, proč by OSS neměl být k dispozici i pro 64bit, když si tak uživatel přeje.

[Michal Fecko]

Moc dobře víš, že čistě 64bitová linuxová instalace není problém.

Aj Debian?

[__dark__]

Já mám gentoo a teď si pohrávám s archem, takže nemůžu sloužit

[michich]

Zejména Debian, kde port na amd64 byl od začátku dělán jako "pure", kde dodnes není rozumně vyřešen multilib/multiarch a místo toho se kompatibilita pro 32bitové programy řeší přes podivnost ia32-libs.

[trekker.dk]

Proč podivnost? Když chceš provozovat programy překládané pro jinou architekturu, prostě si nainstaluješ balík, který ti to umožní. Multilib/multiarch není potřeba, odhaduju, že v 99% případů se bez toho obejdeš.

[michich]

ia32-libs je nesystémové, nekompletní a málo aktualizované.

[chrono]

OSS môže byť dostupné aj pre 256 bitové architektúry, ak sa o to ten používateľ postará (alebo: prečo by to mal robiť programátor toho programu, keď to on sám nepotrebuje?).

[__dark__]

Aneb jak přemístit diskuzi k úplné kravině, že...

[Grunt]

Moc dobře víš, že čistě 64bitová linuxová instalace není problém.

+1

Též to nechápu, zvláště když jádro je otevřené a nikdo mu nebrání vymazat si /usr/src/linux/fs/compat_binfmt_elf.c a si tam do volání doplnit něco na způsob:

    …
    printk("ELF loader: Takové 32-bitove smejdarny odmitam zavadet a laskavy uzivatel si je muze strcit do…");
    return 1;
  }

Pak bude mít teprve jistotu, že jediná 32-bitová instrukce neprojde.

[trekker.dk]

Jestli není jednoduší místo zásahů do zdrojáků prostě použít přepínač v .config

[Grunt]

No jo, vida. Kdo by to řekl. Ale s takovým popisem není divu, že jsem to přehlédl:

          If you find that after upgrading from Linux kernel 1.2 and saying Y
          here, you still can't run any ELF binaries (they just crash), then
          you'll have to install the newest ELF runtime libraries, including
          ld.so (check the file <file:Documentation/Changes> for location and
          latest version).

config COMPAT_BINFMT_ELF
        bool
        depends on COMPAT && BINFMT_ELF

config BINFMT_ELF_FDPIC
        bool "Kernel support for FDPIC ELF binaries"
        default y
        depends on (FRV || BLACKFIN || (SUPERH32 && !MMU))

[xvasek]

Moc dobře víš, že čistě 64bitová linuxová instalace není problém.

...ale samotná 32bit binárka bude fungovat v systému, který je jinak 64bit, ne? Až někdo vyhlásí, že od 2.6.38 už to tak nebude, tak nastává ten čas, kdy by uživatel měl začít mít strach, co bude s jeho oblíbenými 32bit aplikacemi.

[Grunt]

Až někdo vyhlásí, že od 2.6.38 už to tak nebude, tak nastává ten čas, kdy by uživatel měl začít mít strach, co bude s jeho oblíbenými 32bit aplikacemi.

Pokud jsou ty oblíbené aplikace Open Source nebo Free Software, tak nějaké bity naprosto nehrají roli.

[Jardík]

Ne, pokud máte 64bit kernel bez podpory 32bit binárek (dá se vypnout/zapnout), tak vám fungovat nebude.

[Grunt]

Proč se proboha neregistruješ?

[default]

S Jardíkem?

[JS]

Současný stav je jen přechodný a budoucnost desktopů a serverů patří právě 64bitové architektuře.

Vazne? Ja tedy nevim. Na 64-bitove architekture, jestli se nepletu, maji pointery 2x vetsi delku a vetsinou v te horni pulce budou nuly. Coz mi prijde, ze bude zabirat podstatne vic pameti. Takze ja jsem s tou budoucnosti ponekud skepticky.. Nicmene rad se necham opravit/presvedcit.

[__dark__]

Data aplikací se přece neskládají jen z ukazatelů. Ano, ukazatele jsou větší, ale to znamená i to, že aplikace může pracovat s větším množstvím paměti. Aplikace plýtvají pamětí úplně někde jinde.

64bitová architektura nabízí mnohem víc - více registrů, větší šířka, gerantované SSE2, nové optimalizované volací konvence, atd... (pokud se bavíme o x86/amd64). Přiznávám, že amd64 je tak trochu bastl, ale tato architektura se uchytila a bude s náma ještě hodně dlouho.

[JS]

To jo, 64-bitova architektura obecne (jako registry apod.) je nesporne uzitecna, ale ja mam pochybnosti o 64-bitovem adresnem prostoru a o 64-bitovych pointerech. Vetsina aplikaci (zatim dikybohu) nepotrebuje vic nez 2 GB. Pak je to plytvani pameti (tedy, ono je to plytvani pameti i tak, i pro nejdrsnejsi aplikace by bohate stacil 48-bitovy adresny prostor).

[Marek Bernát]

Čože to? Podľa Moora sa nám všetko zdvojnásobuje každý rok a pol, ak ma pamäť neklame. Dnes sme na tých 2GB, takže o 20 rokov sa budeme blížiť 2^48B. A to hovorím len o bežných počítačoch. Existujú konfigurácie s podstatne väčším množstvom pamäte. A čo sa aplikácií týka, tie dnešné toho tiež nerobia o moc viac jak tie pred 20 rokmi. Pritom tie kedysi si bohate vystačili s 48kB

[Ladicek]

Podle Moora se každých X let zdvojnásobuje hustota integrace. Interpretaci, podle které by se každých X let zdvojnásobovaly paměťové nároky softwaru, jsem ještě neslyšel Mimochodem X bylo původně tuším 1, pak 1,5 a dneska se říká spíš 2. A spekuluje se o tom, že za pár let bude X někde u +∞

[Marek Bernát]

Ja mám teóriu, že pamäťové nároky aplikácií rastú rýchlejšie než exponenciálne. Inak si neviem vysvetliť, že v prehistórii stačilo pár kilo pamäte úplne na všetko a dnes už nestačia gigabajty na nič

[Ladicek]

Já mám teorii, že lidi, kteří tohle říkají, si asi nepamatují, že textový editor v těch pár kilech paměti neměl ani undo. A jestli bude za deset let KCalc chtít 100 GB paměti a 100jádrový procesor, tak mi to nevadí – protože s tím pravděpodobně zvládne faktorizovat 4096bitové číslo

[Marek Bernát]

To nie je vôbec pravda. Undo editory zvládajú už poriadne dlho. Ostatne, na pamätanie si rádovo 100 elementárnych úprav (nie je dôvod, aby ich bolo nekonečne veľa) zas tak moc pamäte netreba, že áno

Jasné, že dnešné aplikácie toho dokážu viac, ale pomer schopnosti/spotreba podľa mňa ide rýchlo k nule (čitateľ rastie polynomiálne, menovateľ exponenciálne). Tak či onak, nič to nemení na mojej teórii, že nároky aplikácií rastú rýchlo. Takže o tých 20 rokov tu skutočne budeme mať aplikácie, ktoré budú spotrebovávať 2^48B. Že toho budu vedieť viac ako tie dnešné je nepochybné. Že budú vedieť niečo výrazne užitočnejšie, čo tu dnes ešte nemáme, s tým by som už polemizoval

[Grunt]

Přesně tak. Nejen že editory z 8-bitové éry uměly UNDO, ale uměly toho ještě spousty navíc a v podstatě si troufnu tvrdit, že ty hlavní funkce se od těch dob nezměnily. A šlo to i s 48kB paměti. (Budiž, uznávám že s formátovaným textem byl docela problém v těch dobách, zas to na oplátku umělo jiné vychytávky) Jako příklad bych si dovolil uvést dva geniální editory vim a emacs, které fungovaly i na tehdejších počítačích.

[Ondrej 'SanTiago' Zajicek]

Oni take pozadavky uzivatelu rostou - napr tehdy mel framebuffer nejakych 150 kB (640x480 16 barev), dnes ma 8.8 MB (1920x1200 32bit)

[Grunt]

6910B, tedy přibližně 6,7kB v případě ZX Spectra^[1]. 6114B na pixely a 768B na barevné atributy (v podstatě to fungovalo skoro jako JPEGy bez transformace a komprese). 150kB neměly dlouho ani IBM PC a rozlišení 640x480, to neměl ani Doom.

[Ondrej 'SanTiago' Zajicek]

150kB neměly dlouho ani IBM PC a rozlišení 640x480, to neměl ani Doom

150 kB zabira standardni rozliseni 640x480 16 barev, ktere bylo bezne pouzivane aplikacema. Hry (jako Doom) obvykle pouzivaly 320x200 256 barev (64 kB). V obou pripadech jde o rozliseni dostupna na beznych VGA kartach.

[Grunt]

ktere bylo bezne pouzivane aplikacema

Takových si krom 602 a QBASICu nepamatuju (ale je pravda, že v těch dobách já spíš hrával hry). VGA už je ovšem moc pokročilé. V dobách zlaté 8-bitové éry měly díky inženýrskému rozhodnutí módy z dílen IBM limit 16000 bytů z VideoRAM/framebufferu. Viz seriál Pavla Tišnovského.

[Marek Bernát]

Moje požiadavky nerastú. Väčšina aplikácií, ktoré dnes používam, sú tu už 20 a viac rokov

[Ondrej 'SanTiago' Zajicek]

Pouzivas 20 a vic let stejne rozliseni?

[Marek Bernát]

Tak netvrdím, že si tiež neužijem väčší komfort, keď to ide; masochista nie som. Skôr mi išlo o to, že pred 20 rokmi by sa mi na počítači nepracovalo oveľa horšie ako dnes.

[xkucf03]

Mám tu jednu třiosmšestku s 8 MB RAM, nechceš pracovat na ní? To by ti mělo stačit

[Grunt]

Nechápu proč vytahuješ největší krámy všech dob. Proč radši nevytáhneš nějakou Amigu (klidně i s menším množstvím paměti nebo starší model než ekvivalent v domá 386 s 8MB RAM) pro které ještě dnes vznikají operační systémy a aplikace a pak se nezeptáš třeba amigapowera jestli s nima nechce pracovat?

[Grunt]

No, vida. 8MB RAM neměla ani Amiga 4000T.

[xkucf03]

Náhodou, i s tou 386 jsem si hodně užil. Amigu hodnotit nemůžu, protože tu jsme doma nikdy neměli.

[Marek Bernát]

386 bol môj prvý počítač, keď som mal 6 rokov. Ale vtedy som len hrával hry a neskôr sa trošku hral s BASICom, to bolo všetko. Ale bohate mi to stačilo Dnes už by to bolo trochu horšie, lebo človek je rozmazlený, ale na 386 sa určite dá pracovať stále

[Marek Bernát]

Bohužiaľ, žiadny z týchto skvelých počítačov som nikdy nemal Vynahradzoval som si to aspoň hraním hier zo ZX-spectra a amigy v emulátoroch

[Ondrej 'SanTiago' Zajicek]

Nechápu proč vytahuješ největší krámy všech dob. Proč radši nevytáhneš nějakou Amigu

Myslim, ze si to moc idealizujes. Vetsina Amig (v ramci uspor) nemela MMU, takze aplikace si (bez ohledu na OS) navzajem mohli prepisovat pamet a shodit cely system. Coz me prijde jako znacne suntova vlastnost. Oproti tomu na 386 s 8 MB RAM lze provozovat rozuymne operacni systemy (izolace procesu, vynutitelna uzivatelska opravneni).

[Grunt]

Amiga neměla spoustu věcí ( především nějaký výkonný 3D akcelerátor, což jí IMHO zlomilo vaz nejvíce ) což ovšem nemění nic na tom, že některé prvky předčili svou dobu a znovu se po několika letech začínají jakoby znovuobjevovat.

[Ondrej 'SanTiago' Zajicek]

především nějaký výkonný 3D akcelerátor, což jí IMHO zlomilo vaz nejvíce

Nemyslim. V dobe, kdy se na PC zacaly vyrazneji pouzivat 3D akceleratory (~ 1997), tak jiz Amiga byla davno mrtva. Nicmene s 3D to souvisi - v dobe, kdy se na PC zacaly byt popularni 3D akcni hry (tehdy ciste softwarove pocitane), mely uz mainstremove Amigy dost slabsi procesory nez PC, takze ty 3D hry neutahly.

[Grunt]

No však. Kdyby v těch dobách ('93,'94) přišla s 3Dfx Voodoo jako součástí Amiga OCS, dovolil bych si tvrdit, že by se z ní stal The ultimate alien ass kicker veškeré tehdejší konkurence a dnes by jsme si nepsali pomocí potomků i386. Procesor stačil.

[VSi]

Docela odvážné tvrzení. Skutečně měla dostupnost her, resp. později 3D akcelerátorů, takto zásadní vliv na úspěch platformy IBM PC resp. i386? Jaký podíl prodaných i386 strojů v té době sloužil alespoň částečně ke hraní her?

Do teď jsem byl přesvědčen, že masivní úspěch IBM PC architektury spočívá v tom, že existovaly kompatibilní počítače a jejich jednotlivé komponenty mohly dodávat různí výrobci (a dodnes tomu tak je). To otevřelo cestu k nižším cenám a volnému vývoji, který nebyl řízen jedinou firmou (viz Apple a jejich opakovaná špatná rozhodnutí). Podstatné bylo, že operační systém se dal koupit zvlášť bez vazby na HW.

Pokud vím, tak u strojů typu Amiga nebo Apple bylo v podstatě nekolik typů, které šlo do určité míry konfigurovat a rozšiřovat. Ale architektura IBM PC dávala v tomhle nesrovnatelně větší možnosti.

V naznačené době 93, 94 už bylo rozšíření PC daleko větší než strojů Amiga, ne? Takže proto byla 3Dfx Voodoo zrovna pro PC. Amiga pravděpodobně propásla šanci daleko dříve, stejně jako Apple.

[Ondrej 'SanTiago' Zajicek]

Kdyby v těch dobách ('93,'94) přišla s 3Dfx Voodoo jako součástí Amiga OCS,

V te dobe take nikdo nic (v oblasti osobnich/domacich pocitacu) takoveho nemel. Takze kdokoliv by to nabidl, tak by pravdepodobne dost ziskal. Ale to je dost spekulace, v te dobe uz Amiga neprisla ani s odpovidajici 2D grafikou (proto se jako rozsirujici karty pro Amigy prodavaly karty zalozene na chipech vyvijenych primarne pro PC - chipy od S3 nebo Cirrus Logic). Oproti tomu zminovane rozumne MMU mely v te dobe prakticky vsechny nove PC (od procesoru 386 vis).

[Jardík]

Já mám např. 16GB a 32bit šmejďárna je teda neadresuje (leda tak ve Windows, ale to potřebuje admin práva a snad žádný SW, co znám, to nepoužívá).

[kralyk z abclinuxu]

A která 64-bit aplikace těch 16GB adresuje, resp. využije? Tím nechci říct, že 64-bit je nahouby, jsem s tebou zajedno, že 64-bit je správná cesta, ovšem 16GB RAM bych si (na desktop/ntb) opravdu nekoupil, protože ve chvíli, kdy bude skutečně tolik RAM potřeba, už bude existovat komplet nové rozhraní pro RAM a to současné bude zasstaralé a pomalé.
Leda pokud na tom PC provozuješ nějaké vědecké výpočty, hodně editace videa, či podobně náročné úlohy, to pak jo...

Já mam problém využít svých 4GB RAM

[__dark__]

Třeba databázový server

[Heron]

Grafické aplikace (entry level 10MPx zrcadlovka -- obrázek má 60MB nekomprimovaných dat), vědecké počítání nebo, pokud je to na tebe moc hardcore, tak třeba prohlížeč -- ano, i ten mi sletěl při běžném prohlížení, měl naalokováno přes 1.5GB a nebyl to memory leak.

[Grunt]

Ale dej furt pokoj s grafickými aplikacemi. To není tak klíčové. Existuje spousty jiného využití než jen ořezávání 10Mpix 48-bitových Photoshopem.

[default]

Ale dej furt pokoj s grafickými aplikacemi.

Třeba Livu by dost bodlo, kdyby byl čtyřiašedesátibitovej. Specielně tý verzi Suite, která obsahuje nějakejch tuším 100 GB samplů a nástrojů. Sice tam maj pre-loading, ale do těch tří giga se toho fakt moc nevejde…

[Grunt]

Zas určitě nějaký krám.

[Heron]

Když pro mě jsou ty grafické aplikace klíčové.

[Grunt]

Bo si lama a neumíš kouzlit v ImageMagicku

[Heron]

Jakým kouzlem přesně v ImageMagicku dosáhnu realtime náhledu při nastavování parametrů převodu z RAW?

[Václav HFechs Švirga]

<rýpavý blbý joke> Jaký realtime, si prostě vyjedeš charakteristiky, předem si úpravu promyslíš a pak to napíšeš jako parametry, zmáčkneš enter a něco to vyplivne. Pokud je to hnusné, je to jedno, vnímání je relativní </rýpavý joke>

[Heron]

No, to až tak rýpavé není. Někdy mám pocit, že přesně takto s obrázky a zvuky pracuje Grunt .

[Václav HFechs Švirga]

To víš.. orkové

[default]

S videi také.

[Heron]

S těmi především

[kralyk z abclinuxu]

+1

[frEon]

myslim, ze tohle kouzlo to zvladne

[Grunt]

Abrakadabra…jen blbě rýpu.

[Grunt]

No ale když už jsme teda u toho: ImageMagick je sekvenční procesor (teda aspoň convert). Vstup, požadované akce, výstup. Na výsledek aniž by si ho musel uložit se můžeš podívat tak, že jako výstup nepoužiješ nějaký soubor, ale show: (stejně tak se můžeš podívat na mezivýsledky pomocí operátoru -write show: kdekoliv v pipelině). Uznávám že to není moc šikovné pokud člověk není zrovna core ultras a že by možná nějaké šoupátka občas bodly, ale zas si těžko představit jak se to u něčeho takového implementuje. Já osobně to řeším tak, že pokud už nějaký parametr potřeba poštelovat je, tak využiju smyčky, poukládám to do YUV sekvence a pak na to pustím Mplayer.

[default]

Já osobně to řeším tak, že pokud už nějaký parametr potřeba poštelovat je, tak využiju smyčky, poukládám to do YUV sekvence a pak na to pustím Mplayer.

A jak řešíš ICC profily?

[Grunt]

YUV420p? To pomalu neřeší ani barvy, natož nějaké ICC. Ale jako náhled to stačí. Máš-li lepší nápad, rád si ho vyslechnu.

[default]

YUV420p? To pomalu neřeší ani barvy, natož nějaké ICC. Ale jako náhled to stačí.

Což je ten nejlepší způsob, jak nalézt nejlepší kombinaci parametrů.

Máš-li lepší nápad, rád si ho vyslechnu.

Nepoužívat CLI za každou cenu; a při manipulaci s obrázky používat nástroje k tomu určeným. Mimochodem — i videa mají své barevné prostory a profily.

[Ondrej 'SanTiago' Zajicek]

Zrovna imagemagick je v tomhle ohledu dost naivne napsany a zbytecne alokuje spousty pameti i na operace, ktere by slo delat proudove s minimem pameti. Pro zpracovani gigabajtovych obrazku jsou vyrazne lepsi nastroje zalozene na libvips, at uz konzolove (vips-tools) nebo graficky interaktivni nip2.

[Grunt]

Zrovna imagemagick je v tomhle ohledu dost naivne napsany a zbytecne alokuje spousty pameti i na operace, ktere by slo delat proudove s minimem pameti.

Pokud je to rýpnutí do obrázkového stacku, tak na tom se už pracuje. Holt se s tím při návrhu nepočítalo. Jinak tu ale furt je pro tvrďáky in-place batch processing. To neplýtvá ani bitem.

[Ondrej 'SanTiago' Zajicek]

Odkazovany mogrify srada pameti uplne stejne jako zbytek imagemagicku (tedy nacte a dekomprimuje cely obrazek do pameti bez ohledu na provadene upravy).

[Grunt]

Samozřejmě i s tímto se umí IM vyrovnat.

[Grunt]

Já mam problém využít svých 4GB RAM

Jo? Tak si zkus někdy zjistit kolik virtuální paměti sežerou ty tvoje 4GB paměti fyzické a pak se můžeme začít bavit o tom jak 64-bitové pointry jsou plýtvání. Ale samozřejmě to není jen o tom. 32-bitové pointery mají spousty nám ukrytých limitů o kterých ani mi běžní smrtelníci nevíme.

[kralyk z abclinuxu]

Jo? Tak si zkus někdy zjistit kolik virtuální paměti sežerou ty tvoje 4GB paměti fyzické a pak se můžeme začít bavit o tom jak 64-bitové pointry jsou plýtvání.

Ale o tom se vůbec bavit nechci. Podle mě 64-bit pointery [významné] plítvání nejsou...

[Grunt]

No tak to jsem potom tu ironii u A která 64-bit aplikace těch 16GB adresuje, resp. využije? moc nepochopil.

[kralyk z abclinuxu]

Tím jsem myslel, která běžná aplikace skutečně 16GB (nebo podobné číslo) paměti zabere. S velikostí pointeru to ani tak nesouvisí...

[Grunt]

Věřím, že spousty. Teda pokud se bavíme o paměti virtuální (což je také důvod, proč 64-bitové pointery a jiné adresovací kraviny vymýšlí). Např. epiphany (a to je docela štíhlík oproti jiným) se dvěma záložkami si vezme 488MiB virtuální paměti (z čehož je asi jen nějakých 20% ta skutečná fyzická).

[__dark__]

Aneb webkit in action

[Grunt]

No jo. Už o Netsurfu o víkendu budu muset něco malého sesmolit.

[kralyk z abclinuxu]

Zaprvé, většina virtuální paměti je obvykle tvořena mezerou, která nezabírá místo ani v RAM ani na swapu. Můj firefox, na kterém teď píšu má virtuální velikost 956MB, skutečnou 165MB+sdílená 36MB. Využití RAM je 0.7GB. Vužití swapu je nulové.

Zadruhé, já se bavím o fyzické paměti 16GB (kterou má Jardík) a ptám se, která běžná aplikace tohle využije alespoň z poloviny nebo víc. Epiphany, které jsi zmínil to nevyužije ani virtuálně (s mezerou), natožpak fyzicky, takže to asi nebude vhodný kandidát, že...

[Ondrej 'SanTiago' Zajicek]

Zaprvé, většina virtuální paměti je obvykle tvořena mezerou, která nezabírá místo ani v RAM ani na swapu

Jenze ta je tam implicitne a nezapocitava se ani do toho ukazatele zabrane virtualni pameti procesem.

[kralyk z abclinuxu]

Tak kam se podělo těch ~700 MB? Když si vypíšu pmap onoho procesu, je tam spousta segmentů označených jako anonymní, jsou to voni? Na swapu nic není...

[Ondrej 'SanTiago' Zajicek]

Alokovana ale nepridelena pamet? (tam muzou spadat i ty anonymni segmenty). Nebo casti prilinkovanych knihoven, ktere nejsou natazene v pameti (tady si nejsem jist, zda se to pocita do sdilene nebo ne)? Mmapovane ale nenatazene soubory?

[Heron]

Zadruhé, já se bavím o fyzické paměti 16GB (kterou má Jardík) a ptám se, která běžná aplikace tohle využije alespoň z poloviny nebo víc.

Třeba POVRay. Nebo 7zip. Nebo ty slučovadla obrázků v Huginu. Nebo PostgreSQL.

[Marek Bernát]

Stalin napr.

[Heron]

A čo sa aplikácií týka, tie dnešné toho tiež nerobia o moc viac jak tie pred 20 rokmi.

Opravdu? Ty aplikace možná dělají totéž (ale ani to není vždy pravda, dřív nebylo ani undo, dneska máš kompletní správu verzí), jenže na mnohonásobně větší vstupy a s mnohonásobně většími výstupy. A zatímco tehdy tam RAM sotva stačila pro kód programu a vstup se musel vejít do toho zbytku (nebo se zpracovával velmi pomalu po částech), tak dnes je tomu právě naopak. Drtivou většinu paměti zabírají data, různé cache apod. Je to daleko levnější, než to počítat znovu.

[Marek Bernát]

Ale veď nie sme v spore. Ja netvrdím, že dnešné aplikácie nie sú lepšie. Len že strašne plytvajú. A tiež si nemyslím, že je to problém. 1GB RAM stojí dnes pár káčok, takže by vývojár bol debil, keby skúmal, ako ušetriť bajty

Ber to skôr ako povzdych za dobami pravých mužov, ktorí ešte ovládali počítače do posledného kolieska a písali fantastické programy, ktoré nevyužili ani bajt navyše

[Heron]

Ber to skôr ako povzdych za dobami pravých mužov, ktorí ešte ovládali počítače do posledného kolieska a písali fantastické programy, ktoré nevyužili ani bajt navyše

Dobrá. Ono se na to dá dívat i jinak: neskutečně plýtvali strojovým časem, místo aby si výsledek uložili do paměti . Je to pouze o ceně. Tehdy byl levnější CPU a paměť strašně drahá, dneska je to naopak. jj, nejsme ve sporu.

[xkucf03]

A třetím faktorem je cena lidská práce – někdy (dneska často) vyjde levněji nechat pracovat počítač a plnit paměť a disky, než trápit programátora a platit jeho čas (aby nad tím proseděl několikrát víc hodin a dosáhl o trochu úspornějšího řešení). Vždycky je to o hledání optimálního řešení – a to se v závislosti na cenách zdrojů mění.

[default]

A čo sa aplikácií týka, tie dnešné toho tiež nerobia o moc viac jak tie pred 20 rokmi.

No dobrá. Principielně máš pravdu, ale realita je někde jinde. Zatímco před dvaceti lety jsem si pípal na PC Speaker, dnes peru do zvukovky dvacet virtuálních nástrojů přes řetězce filtrů pod tlakem až 24bit/192kHz ve stereu (né, že by moje karta neuměla těch kanálů víc občas používám druhou dvojičku pro příposlech).

A nebo grafika. Tenkrát jsme si hráli s jehličkovejma tiskárnama, dneska má doma každej fototiskárnu. Tenkrát byly editory typu Text602, dnes máš InDesigny…

Objemy zpracovávaných dat vzrostly z jednotek kilobytů na jednotky až desítky gigabytů na projekt. Například projekt bookletky CD, potiskem CD a obalem mi zabírá v průměru 500 až 700 MB.

[Grunt]

Zatímco před dvaceti lety jsem si pípal na PC Speaker

A nebo někteří využívaly geniálních inženýrských řešení té doby jako jsou trackování nebo wavetably (v podstatě to stejné co dnes, jen mnohem ekonomičtější). Můžu říct, že to co dnes používáš jsou největší inženýrské SHITy k jakým se dá vůbec dostat.

[default]

Ale no jasněé. To by nebyl Grunt.

[kralyk z abclinuxu]

ale ja mam pochybnosti o 64-bitovem adresnem prostoru a o 64-bitovych pointerech. Vetsina aplikaci (zatim dikybohu) nepotrebuje vic nez 2 GB. Pak je to plytvani pameti (tedy, ono je to plytvani pameti i tak, i pro nejdrsnejsi aplikace by bohate stacil 48-bitovy adresny prostor).

To je možné, jsem ale přesvědčen, že při nahrazení 16-bit prostoru 32-bit prostorem byla situace podobná. Nikdo z koncových uživatelů si nebyl jistý, že to opravdu využije. No a kde jsme dnes?

[Ondrej 'SanTiago' Zajicek]

To je možné, jsem ale přesvědčen, že při nahrazení 16-bit prostoru 32-bit prostorem byla situace podobná. Nikdo z koncových uživatelů si nebyl jistý, že to opravdu využije.

No to ani zdaleka nebyla. V dobe, kdy se na osobnich pocitacich rozsirily 32b operacni systemy, uz davno mely pocitace nekolikrat vic pameti, nez kolik jich je mozne adresovat v 16b (realnem) rezimu procesoru (cca 1 MB, ten prostor byl kvuli segmentaci v podstate 20 bitovy). Dodatecna pamet se vyuzivala pomoci krajne nepohodlnych triku jako XMS a EMS. Nehlede na to, ze realny rezim mel proti 32b protected rezimu radu dalsich znacne nepraktickych omezeni (nepritomnost MMU, 16b segmenty).

Jeste tu tedy byl 16b protected rezim, umoznujici adresovat az 16 MB pameti, ale ten se nikdy moc nepouzival.

[__dark__]

Jak jsem psal, podle mě je velikost ukazatele zanedbatelná.

Dám příklad, obrázek na desktopu je většinou uložený ve formátu XRGB32, jeden BYTE pro každý pixel je nevyužitý. Pokud mám rozlišení 1920x1200, tak obrázek zabírá 9.2MB paměti, z toho 2.3MB je nevyužitých. Další příklad může být třeba rezervování zbytečně veliké kapacity pro datové kontejnery, kódování UTF-32, atd...

Žravost aplikace se nevyznačuje architekturou, ale programátorem a prostředím, které daná aplikace využívá (tím myslím i programovací jazyk/vm, sw knihovny, ...).

[Ondrej 'SanTiago' Zajicek]

Žravost aplikace se nevyznačuje architekturou, ale programátorem a prostředím, které daná aplikace využívá (tím myslím i programovací jazyk/vm, sw knihovny, ...).

Obecne souhlasim, ale jsou i pripady, kdy velikost ukazatele zanedbatelna neni. Napriklad route servery v peeringovych centrech maji stovky MB az gigabajty v routovacich tabulkach, coz je v podstate spousta malych strukturek plnych pointeru.

[JS]

Jak uz psal Ondrej, zalezi na aplikaci. Nektere aplikace - jako treba objektove-orientovane programy (GUI) nebo virtualni stroje pro interpretovane jazyky - jsou velke mnozstvi pointeru. Takze bych si rozhodne netroufal tvrdit, ze budoucnost patri jednoznacne 64-bitove architekture - ja to vidim spis na nejaky hybrid 32/64.

[Ladicek]

Takové 64bitové JVMko by mělo (tuším až od verze 7) ukazatele komprimovat (viz třeba http://wikis.sun.com/display/HotSpotInternals/CompressedOops nebo http://www.elis.ugent.be/~leeckhou/papers/ecoop07.pdf). Takže problém to určitě představuje, ale zdá se, že ne neřešitelný.

[JS]

No vidite, a staci aby nekdo pridal HW podporu pro takovou kompresi (napr. nove instrukce), a hybridni architektura je na svete.

[__dark__]

Co může vyřešit hybrid 32/64? Do dvou let bude snad každý nový počítač obsahovat 8GB/více RAM, takže i kdyby každá aplikace spotřebovala 2x více paměti (což je podle mě nesmysl), tak se vyplatí mít 64bitový OS + veškeré aplikace/knihovny. Podle mě spíš model 32/64 (něco 32bitové a něco 64bitové) je mnohem horší, protože člověk natahuje do paměti knihovny pro 2 různé architektury (takže ve výsledku může právě ten hybridní model spotřebovat mnohem víc paměti).

Za pár let podle mě vznikne i 64bitová architektura pro mobilní platformy, protože některé mobily už dnes obsahují 1GB RAM a k překonání té 4GB hranice bude stačit už jen pár let

[Luboš Doležel (Doli)]

A co mmap()? Užitečná věc, které se vyhýbám jako čert kříži, protože dokud bude svět plný 32bit CPU, není to univerzální náhrada klasického I/O.

[petris_]

chování se k typu long, jako by měl tento typ stejnou velikost jako ukazatel) je velmi častá chyba vývojářů, co píšou hlavně pro Linux.

Pokud si dobre pamatuji, tak iso c rika, ze rozdil 2 pointeru je typu short, int nebo long a ze long neni mensi nez short nebo int, z toho mi plyne, ze ukazatel by se mel do longu vzdy vejit. Vam snad ne?

[Heron]

To není póza. Jardík to sice říká svým způsobem, ale je dobré, že to říká a něco pro to i dělá (kromě té osiny v zadku).

[solomon short]

bez jardika a ladika (asi nejaka verze CZ,no!) by byl cesky internet takovy smutne prazdny :D

[grim]

tortoisegit nevyhovuje?

[Jardík]

Asi neumíš číst. Přečti si jeho závislosti - msysgit.

[Jakub Suchy]

SmartGit?

[Jardík]

Taky v javě, taky používá jgit, problém je nekomerční použití, které by mi mohlo v budoucnu bránit tento SW používat....

... no to je šmejďárna, proč v adresáři lib má jgit.jar a pak to na mě vybafne s hláškou "SmartGit requires a compatible Git instalation on your system" a odkazuje mě na msysgit. Děkuji, nechci.

[Marián Kyral]

Taky v javě, taky používá jgit, problém je nekomerční použití, které by mi mohlo v budoucnu bránit tento SW používat....

... no to je šmejďárna, proč v adresáři lib má jgit.jar a pak to na mě vybafne s hláškou "SmartGit requires a compatible Git instalation on your system" a odkazuje mě na msysgit. Děkuji, nechci.

Wrapper?

[Grunt]

Ty, Msys možná je 32-bitová šmejďárna, ale nevyužívá čirou náhodou služeb MinGW u kterého existuje volba generování 64-bitového kódu a díky tomu že má závislosti jen na WinAPI a netáhne si sebou žádné knihovny (jako v případě Cygwinu) by teoreticky ve výsledku nemusela být jediná 32-bitová instrukce, ne? Jinak nechápu proč se donekonečna snažíš o používání Windows a přitom tak trváš na 64-bitové čistotě. Ty dvě věci se vylučují snad už z principu, ne?

[retroslava]

TortoiseGit-1.5.2.0-64bit.msi ?

[Grunt]

Jo, na ten bych úplně zapomněl a přitom ho sám používám (je to ta želva, ne?). Dokonce to přidá některé GIT specific příkazy do rozevírací nabídky.

[Jardík]

Jak jsem již zmínil, toto je pouze rozšíření pro průzkumníka, ale vyžaduje to msysgit.

[xkucf03]

$ file `which git`
/usr/bin/git: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped

Windows jsou pozadu, ale to je tvůj problém, máš používat pořádný systém :-P

[Marek Bernát]

A ktorý to je? :-P

[xkucf03]

Vždyť to tam je napsané

…dynamically linked (uses shared libs), for GNU/Linux…

[Marek Bernát]

Asi zle vidím. Nikde tam nie je, že je to poriadny systém

[Jardík]

To není věc systému. Vývojář gitu (Linus?) si hold zvolil, že bude používat POSIXové fce. Já mu to nevyvracím. Ale pak je jasné, že to ve Windows nepůjde a musí se to řešit bastlama typu cygwin/msys.

[mkoubik]

Protože to je SCM primárně určené pro vývoj linuxového jádra, na windows si používej bazaar nebo mercurial, nebo popros maminku, ať ti nějaké SCM napíše.

[Jardík]

Já nevím, proč ti tohle vůbec vylezlo z úst. Já maminku prosit nepotřebuju, říkám, že si to píšu ....

[mkoubik]

Protože mi vaděj rozmazlený frackové, kterejm někdo něco dá zadarmo i se zdrojákama a oni by ho nejradši ukamenovali, že to napsal blbě. Tady je tvoje klučíkovský pořvávání o to trapnějsí, že to Linus nepsal pro tebe, ale primárně pro sebe a svoje kolegy, že to může používat i někdo jinej je jenom bonus.

[Jardík]

Copak já Linusovi nadávám? Já jsem přede uznal, že je to jeho věc, já jenom říkám, že to je důvod, proč se to musí ve Windows řešit bastlama.

[mkoubik]

Tak to jsem asi špatně koukal, myslel jsem, že celej problém pramení z toho, že ve windows nejde udělat cd git/src; ./configure; make; make install (což není Linusův problém) a proto se musí používat nějaká knihovna, která dělá to samé co CLI gitu. Pokud je problém v tý knihovně, tak si v předchozích příspěvcích dosaď za Linuse autora tý knihovny.

[default]

Protože mi vaděj rozmazlený frackové, kterejm někdo něco dá zadarmo i se zdrojákama a oni by ho nejradši ukamenovali, že to napsal blbě.

Toto jednání mi moc férové nepřipadá. Když něco pro někoho dělám, měl bych to dělat vždycky poctivě, nezávisle na odměně. Ale to je jen můj pocit, se kterým jsem, koukám, úplně sám…

[mkoubik]

Zato "když to někdo neumí, tak ať to nedělá vůbec" je fér. On snad někoho poškodil tím, že ten kód napsal a vystavil na svém serveru? Nebo snad poškozuje celosvětovou kulturu psaní kódu? Ještě že už nejsou kulturní komise, asi by měl Linus zákaz.

[default]

Ale vůbec né.

Jen se mi nelíbil tvůj výrok, že někdo někomu dodá nedodělek a je překvapen, že to obdarovanému nevoní.

Když něco vystavím na netu a nikomu to nutit nebudu, pak nějaké neslušné reakce jsou opravdu nežádoucí.

Takže s Jardíkem bys měl pravdu, zapředpokladu, že by se nejednalo o užitečný platformě nezávislý nástroj. Jenže, jak jsem to pochopil, Git platformě závislý je. Takže tady se musím Jardíka trošíčku zastat.

[chrono]

Jenže, jak jsem to pochopil, Git platformě závislý je.

Používajú sa tam POSIX vlákna, ale je tam emulačná vrstva a využívajú sa len tie vlastnosti, ktoré sa dajú (primerane zložito/jednoducho) naemulovať aj vo Windows (potom sa používa pár ďalších vecí, ale aj pre ne sú tam náhrady).

Najväčší problém je to, že niektoré príkazy sú shell skripty a teda vyžadujú POSIX kompatibilný shell.

[default]

Najväčší problém je to, že niektoré príkazy sú shell skripty a teda vyžadujú POSIX kompatibilný shell.

Boha jeho! A to vím, o čem mluvím, protože jsem si před měsícem napsal v shellu framework, který podporuje výjimky.

[Murry]

Jsou binarky KDE to Windows (64bit)? Mohl bys nainstalovat kdelibs + gui na git, kterych je pozehnane.
Akorad kvuli jednomu programu bude muset mit pulku KDE. Otazkou co je lepsi - java nebo kdelibs.
Co ty na to?

[xkucf03]

Já jsem takhle do jedněch Windows nedávno instaloval Okular a nebylo to žádné utrpení A musím, říct, že lepší prohlížeč pro Widle asi není – uživatel potřeboval z PDF kopírovat obrázky a Adobe Reader to v některých dokumentech nedokázal, Foxit Reader taky ne (a Evince je fajn, ale tuhle funkci snad vůbec nemá).

[Jardík]

Binárky KDE pro Windows jsou jen 32bit. A dokud Qt bude zabugované, tak ani nemá smysl se snažit je dělat.

[SYSMAN]

Tortoise GIT

[Jardík]

Ty lidi jsou snad navedený ... když si projdeš pár příspěvků, tak ti to třeba dojde.

[M.P.]

Osobně jsem GIT odmítnul Jeho implementace je silně platformně závislá. Zdrojáky není nic, co by člověk měl svěřit bastlu na platformě, kde to nebylo děláno.

Verzovací systémy musí být daleko spolehlivější a musí být na ně kladeny větší kvalitativní nároky, než na cokoli jiného. Protože udržují mnoheletou práci.

GIT je hezká idea, vynikající, ale implementace je neuvěřitelně prasácká. Také jsem se díval, jak je to na Windows, a ono je to závislé na unix shellu.

Tudíž GIT šel pryč. Je to unix only věcička a i tam bych se zdráhal jí něco svěřit, pokud to není uděláno pořádně. Nicméně mimo unix je to hazardérství.

Znovu říkám, idea GITu je vynikající (pokud si odmyslím, že jeho návrhář nezná nic jiného, než low level kernel, takže jsou tam prasečiny typu obrovské množství souborů optimalizovaných na ext2 fs a jiné hovadiny – které by tam být nemusely ale budiž, není to nic co by vadilo tak moc, ale docela dokumentují jak autor byl neschopen vidět mimo svou platformu).

Jediná naděje je, že někdo komplet zahodí veškerou implementaci dělanou linuxáky a napíše jí rozumně a potrabilně znovu. Taková naděje je v Javě, která přepisuje implementaci pro Eclipse. Původní implementační bastl gitu je ostuda.

Vezměte si z tohoto příspěvku co chcete, já jen prezentuji závěry, které jsem si dělal pro sebe. GIT není v dané implementaci vhodný pro neunix systémy. Myšlenka je dobrá. Já osobně bych současné implementaci GITu nesvěřil ani linux zdrojáky, ale kvalita open source jde permanentně dolů, takže lidé jsou zvyklí.

Pokud mně chcete napadat, protože jsem Vám sáhnul na boha, pak vězte, že já to stejně nebudu číst, protože do této diskuse už nevstoupím. Směřujte tedy své rozhořčení směrem k ostatním a pomluvte mně u nich.

[M.P.]

Jinak podpis, Miloslav Ponkrác

[kralyk z abclinuxu]

Jinak podpis, Miloslav Ponkrác

No, to ani nebylo nutné přidávat...

[__dark__]

bot se nemusí podepisovat jménem

[Martin]

Furt dokola ty samé řeči, jak kafemlejnek. Jeden uvidí příspěvek od Miloslava Ponkráce a s 90% úspěšností dokáže odhadnout, o čem se v něm bude pojednávat. Fakt nuda.

[Jardík]

Mně ale nezbývá, než souhlasit. Osobně si to píšu (s použitím té napsané knihovny), jenom abych si mohl procházet commity existujících repozitářů a projektů, které k něčemu využívám, nebo je nějak potřebuju, nebo se o ně jen prostě zajímám. Rozhodně si to nepíšu proto, abych s tím dělal nějaké commity, vytvářel git repozitáře, apod. Prostě takové "naklonuj/aktualizuj repo z netu a koukni, co je nového".

[xkucf03]

A v čem tedy verzuje M.P. a jaký je jeho názor např. na Mercurial?

[pavlix]

Verzovací systémy musí být daleko spolehlivější

Daleko spolehlivější než Git? Ten content-addressed filesystém, na kterém to stojí, mi přijde jako jedna z nejspolehlivějších možností. Dobře popsaný formát, opensource, dobře zálohovatelný. Distribuovatelnost, samozálohovací funkce. Digitální podpisy.

Neumím si představit, co bys vybral spolehlivějšího (i když nepopírám, že se něco takového může najít).

ono je to závislé na unix shellu.

Unix shell ušetří dost práce a naprosto chápu jeho využití. Nevím o žádné významné platformě, kde by nebylo možné shell používat.

Taková naděje je v Javě, která přepisuje implementaci pro Eclipse.

Myslím, že alternativním implementacím se nikdo nebrání.

Jo... trošku ti hapruje stavba věty. Pochybuju, že zrovna Java přepisuje implementaci Gitu.

Původní implementační bastl gitu je ostuda.

Právě naopak, je to ukázka rychlého vyřešení palčivého problému. Současné rozhraní gitu zase dokazuje, že to původní řešení umožňovalo transformaci v rozumné příkazové uživatelské rozhraní.

Směřujte tedy své rozhořčení směrem k ostatním a pomluvte mně u nich.

Tedy aspoň pro ostatní :). Není potřeba tě pomlouvat, stačí uvést tvé nesmysly na pravou míru.

[default]

Původní implementační bastl gitu je ostuda.

Právě naopak, je to ukázka rychlého vyřešení palčivého problému.

Díky. Už vím, co říct zaměstnavateli, až mé řešení nebude u zákazníka fungovat.

[pavlix]

Díky. Už vím, co říct zaměstnavateli, až mé řešení nebude u zákazníka fungovat.

Mno... vzhledem k tomu, že se v současné době věnuju programování a ne technické podpoře, tak to, jestli řešení funguje u zákazníka není naštěstí můj problém :). Můj problém je pouze nedodržení zadání, či způsobení zjevných vad.

V případě Linuse je situace o něco zajímavější, protože zadavatelem je v podstatě on sám, s ohledem na praktické potřeby při údržbě Linuxového jádra (vynechme to, že je ve skutečnosti situace ještě složitější kvůli začlenění práce dalších lidí).

Tudíž člověk, který se rozhodne používat Git na Windows, jednak není ani při největší představivosti zákazníkem, a druhak může Git na Windows vcelku bez problémů použít s využitím Cygwinu.

Využití Cygwinu na Windows nepovažuju za nic sprostého ani nedůstojného.

[Jardík]

Naopak, i kdybych měl 32bit systém, tak by mi cygwin do systému nesměl, je to prasárna plná bordelu používající nedokumentované API s kýblem duplikované práce a zdržujících wrapperů. To už si snad radši nainstaluju nějaký Windows Services for UNIX, jestli to ještě pořád existuje (a jestli to vůbec jde používat).

[Grunt]

LOL, co Ponkrác, to perla.

[Luboš Doležel (Doli)]

GIT není v dané implementaci vhodný pro neunix systémy.

To mi vysvětlete, proč by se Linus měl zabývat neunixovými systémy. Prostě to holt pro Windows nebylo určené, to je toho. Pro Linux zase není psaná tuna dalších věcí.

[podlesh]

Tak to jo, já se klidně přidám s pomlouváním

Typická pokrácovina: v je jádru pravda, ovšem triviální a stará (to že by prvotní implementace gitu je určena pouze pro linux zdrojáky na linuxu a že bude potřeba napsat jinou, portabilní implementaci bylo jasně řečeno snad ještě předtím než se vůbec začalo psát). Navenek je to pak podáno jako geniální myšlenka nepochopeného génia. Guru promluvil a vrátil se meditovat na vrchol hory, kde nebude obtěžován přízemními otázkami nehodných.