Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Jelikož pro Windows (samozřejmě se bavím o 64bit verzi) ještě nikdo nenapsal nativního klienta, rozhodl jsem se něco na ten způsob spatlat.
Pro Windows jsem našel akorát 2 řešení - cygwin+git nebo msys+git - oboje jsou však 32bit šmejďárny. Díky debilnímu platformě závislému buildsystému (čti autotools) se o to ani nemá cenu pokoušet - potřeboval bych cygwin nebo msys (oboje 32bit šmejďárny), nebo bych si musel všechno ručně konfigurovat, psát makefile, ... a výsledek by stejně nebyl jistý - to si každý přetypovává pointery na nějaké longy (dodnes nechápu, proč lidi dělaj takovýhle prasárny), ..
Pak jsem hledal nějakou použitelnou knihovnu. Výsledek nic moc. Pro C++ nic. Pak jsem hledal pro C#. Něco jsem našel, ale nějak to né a né fungovat. Nakonec jsem narazil na JGit (na eclipse.org). Vypadalo to docela slušně, chce to ale javu. Naštěstí existuje pro Windows nativní verze, tak jsem u toho nakonec skončil a rozhodl se to použít.
Jenže ta dokumentace. Naprosto mizivá, prostě "přijď na to sám". Pak jsem narazil na plugin pro NetBeans, tak jsem se ho rozhodl vypreparovat a poučit se, jak tu knihovnu použít. Takže teď tu mám konzolového klienta, co umí pouze jakési git clone
a potom jednoduchý GUI prohlížeč commitů. V podstatě všechno, co potřebuji. Projekty v GITu nespravuji, pouze občas něco potřebuju "naklonovat" a kouknout se, co je nového. Ještě si napíšu GUI pro klonovací nástroj, dodělám to commit GUI (záložka changed files ještě nefunguje), možná ještě nějakou fíčuru navíc a pokud by měl někdo zájem, můžu to pak hodit někam na net.
Tiskni
Sdílej:
Díky debilnímu platformě závislému buildsystému (čti autotools) se o to ani nemá cenu pokoušetOdporúč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).
Pokud git narazí na omezení 32bit architekturyTo 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í.
přetypování ukazatele na long, nebo chování se k typu long, jako by měl tento typ stejnou velikost jako ukazatelOn Git něco takového někde dělá? P.S.: Neplatí to ani na Linuxu.
P.S.: Neplatí to ani na Linuxu.Kdy to na Linuxu neplatí? Na nějaké konkrétní architektuře?
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.
...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.
při instalaci máte možnost neinstalovat WOW64."A komu tím prospějete, co?"
Windows Server 2008 R2 - při instalaci máte možnost neinstalovat WOW64..
To je blbost, žádná taková možnost tam není.
Moc dobře víš, že čistě 64bitová linuxová instalace není problém.
ia32-libs
.
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.
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))
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.
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.
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.
Č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
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č
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
150kB neměly dlouho ani IBM PC a rozlišení 640x480, to neměl ani Doom150 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.
ktere bylo bezne pouzivane aplikacemaTakový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.
Moje požiadavky nerastú. Väčšina aplikácií, ktoré dnes používam, sú tu už 20 a viac rokov
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.
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
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
Nechápu proč vytahuješ největší krámy všech dob. Proč radši nevytáhneš nějakou AmiguMyslim, 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).
především nějaký výkonný 3D akcelerátor, což jí IMHO zlomilo vaz nejvíceNemyslim. 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.
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).
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…
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?
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.
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.
Já mam problém využít svých 4GB RAMJo? 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.
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...
A která 64-bit aplikace těch 16GB adresuje, resp. využije?moc nepochopil.
Zaprvé, většina virtuální paměti je obvykle tvořena mezerou, která nezabírá místo ani v RAM ani na swapuJenze ta je tam implicitne a nezapocitava se ani do toho ukazatele zabrane virtualni pameti procesem.
pmap
onoho procesu, je tam spousta segmentů označených jako anonymní, jsou to voni? Na swapu nic není...
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.
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.
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
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.
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
Zatímco před dvaceti lety jsem si pípal na PC SpeakerA 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.
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?
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.
Ž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.
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?
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?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.
$ 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
A ktorý to je? :-P
…dynamically linked (uses shared libs), for GNU/Linux…
Asi zle vidím. Nikde tam nie je, že je to poriadny systém
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.
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…
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.
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.
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.
Díky. Už vím, co říct zaměstnavateli, až mé řešení nebude u zákazníka fungovat.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.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.
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í.