[04:14] czym ubuntu steruje wiatrakami, bo chodza cicho i nagle otworze film na sekunde czy cos i zaczyna sie wycie... [07:20] wina acpi. [11:17] wina tuska === dudi is now known as xdudi [19:24] hey [19:24] ey [19:25] dzisiaj wgralem ubuntu na netbooka szał hehehe [19:25] extra system [19:27] ok [19:27] ._. [19:28] faktycznie dobry produkt jak za te cene :) [19:28] co kto lubi [19:28] ja bym wolał zapłacić za coś lepszego ;p [19:29] TheNumb: a jest cos lepszego? :) [19:29] xdudi: może. [19:29] Co kto lubi. [19:30] TheNumb: a ty co lubisz? :> [19:31] xdudi: nie zawsze się ma to co się lubi :( [19:32] TheNumb: nie pytalem czy zawsze sie ma to co sie lubi.. :> [19:32] xdudi: a ja nie mam zamiaru odpowiadać na to pytanie. [19:32] Bo nie mam ulubionej dystrybucji :( [19:33] bo... linukz to gunwo :DDDD [19:33] TheNumb: to moze skonkretyzuje pytanie - co wydaje ci sie lepsze od ubuntu? :) [19:33] linux to tylko kernel :P [19:33] xdudi: FreeBSD :( [19:34] TheNumb: bawie sie fbsd ostatnio, jednakze system ma swoje slabosci ktore na ubuntu nie wystepuja [19:34] Słabości? :| [19:34] tak [19:35] Ciekawe jakie <: [19:36] ostatnio probowalem uruchomic swoj soft na nim, wywalalo sie na singletonach, za pomoca specjalnych flag wymuszalem na kompilatorze uruchamianie ich w okreslonym porzadku, na ubuntu dziala idealnie, na fbsd na koniec procesu jest crash [19:36] yyyy [19:36] nie doszedlem jeszcze do przyczyny, byc moze ld tam inaczej dziala [19:36] A czym kompilowałeś? :D [19:36] Może antycznym gcc 4.2.1? [19:36] gcc oraz clangiem [19:36] <: [19:37] gcc47 z paczek :P [19:37] singletony to zuo [19:37] tak btw [19:37] :P [19:37] moze ld w bsd jest inteligentniejszy i sytuacje naprawi omakrowanie __init_priority__ tak aby na bsd go nie bylo :P [19:38] xdudi: nie, ja bym wolał znowu używać os x (: [19:38] moze i sło, jednakze ulatwiaja one wiele rzeczy [19:39] os x... w polsce mieszkasz a nie w usa :P [19:40] xdudi: nie widzę związku. [19:40] tu sie na cebuli siedzi :P [19:40] mhm [19:40] TheNumb: zartuje, nie mam nic do osx, to w koncu fork z freebsd :) [19:40] żaden fork. [19:40] Jedyne co mają z freebsd to userland. [19:41] ps. to prawda [19:41] z biegiem lat kodu z bsd w osx bedzie pewnie coraz mniej [19:41] niebardzo [19:41] ;-) [19:41] http://opensource.apple.com/release/os-x-1092/ [19:41] jednakze co do architektury dystrybucji, bsd bije na ryj ubuntu i reszte ekipy [19:42] podoba mi sie odseparowanie kernela, base systemu od 3rd party softu [19:42] a w dystrybucjach linuxowych to wszystko jest zmielone [19:42] xdudi: widział nix os? (: [19:43] nixos* [19:43] http://nixos.org/ [19:43] nie [19:45] wiec czym on sie rozni od ubu tak w skrocie? [19:46] http://nixos.org/nixos/about.html [19:46] "NixOS is based on Nix, a purely functional package management system. Nix stores all packages in isolation from each other [...]" [19:46] :P [19:47] no widze widze [19:48] szkoda tylko ze jest tak niszowa ta dystrybucja [19:50] 113 miejsce na distrowatch, popularnoscia nie dorownuje nawet netbsd :P [19:51] distrowatch nie jest wskaźnikiem popularności :( [19:51] Sami nawet tak twierdzą. [19:51] jest, lecz bardzo niedokladnym [19:51] Nie jest. [19:53] a co mogloby byc takim wskaznikiem? :> [19:53] Statystyki na steamie! [19:53] :P [19:53] Nie wiem i niezbyt mnie to obchodzi. [19:54] na steamie sa tylko gierki [19:54] masa ludzi pracuje na linuxie w nic nie grajac... [19:55] nie [19:59] xdudi: na distrowatch linux mint jest na pierwszym miejscu :( A przecież powszechnie wiadomo, że to gunwo. [19:59] Tak samo jak Arch na 8. [20:01] TheNumb: ciezko to obiektywnie ocenic.. [20:07] Kurde, podpuszczam tego gjmbusa a ten się nie daje :( [20:07] nie hajlajtuj mnie [20:09] TheNumb: poco robic gownoburze skoro mozemy konstruktywnie porozmawiac :) [20:13] poco [20:13] się [20:13] nogi [20:13] noco [20:18] slyszeliscie moze o syncany? [20:18] tag [20:19] TheNumb: uzywales moze tego? [20:20] xdudi: tak [20:21] TheNumb: i jaka masz o tym opinie? [20:22] xdudi: wolę btsync [20:22] (: [20:23] TheNumb: znasz moze jakies alternatywy do syncany? [20:23] xdudi: btsync [20:23] ; p [20:24] xdudi: syncthing [20:25] TheNumb: nie zrozumiales mojego pytania, chodzi mi o alternatywe do syncany opierajaca sie na podobienstwie do gita [20:26] sparkleshare? [20:26] ;p [20:26] używa gita [20:26] <: [20:27] ale git przechowuje wszystkie rewizje pliku, wiec nie nadaje sie do backupow [20:32] xdudi: inkrementalne backupy [20:32] tak się to nazywa [20:33] poza tym, subversion, lokalnie masz tylko jedną kopię, albo git-annex [20:34] xdudi: SVN [20:34] SVN roksuje rulezem, nie rozumiem ludzi ktorzy lubia sie torturowac gitem [20:35] jacekowski: szanuje twoje zdanie ale svn ma wiele wad ktorych git nie ma [20:35] jakie? [20:36] brak submodulow [20:37] brak normalnych galezi (jakie sa w gicie) [20:37] brak decentralizacji [20:38] svn ma eksternalsy [20:38] decentralizacja jest zla [20:39] brak galezi nie uwazam za problem [20:39] decentralizacja... zła? [20:39] Co kto lubi. [20:39] tzn. implementacja jaka jest w svn jest wystarczajaco dobra [20:39] Dla mnie nie. [20:39] git nie ma lockow [20:39] a na co komu locki? [20:40] zeby moc jakies binarne albo inne niemergowalne pliki edytowac [20:40] To jedno z największych upośledzeń svn. [20:40] w gicie moożesz trzymać binarne pliki. [20:40] Nie ma żadnych przeszkód. [20:40] jacekowski: no dobrze, ale wciaz pozostaje problem branchy... [20:40] w svn tym bardziej [20:41] tylko ze w git jak masz np. automatycznie generujace sie iso [20:41] ktore co rewizje bedzie inne [20:41] to po kilku rewizjach nikt nie bedzie w stanie zrobic clone [20:41] jacekowski: iso? [20:42] plik iso? [20:42] gdzie w svn sciaga sie tylko ostatnia rewizja [20:42] xdudi: tak [20:42] ale kto normalny wsadza iso do gita? [20:42] nikt, bo git tego nie umie [20:42] na ftp rozumiem... [20:42] a svn sobie bez problemu z tym da rade [20:43] ale ftp to nie system kontroli wersji [20:43] zawsze pozostaje w gicie --depth=1 [20:44] jacekowski: moglbys opowiedziec mi o sposobie pracy na galeziach w svn? [20:44] jacekowski: git-annex [20:44] http://howto.praqma.net/subversion/branching-strategies [20:45] xdudi: w duzym skrocie: kopiujesz trunk do branches/branchXX [20:45] a w druga strone robisz merge'a [20:45] BlessJah: ale czy git annex dziala tak ze ja sobie teraz moge nowy komputer wziasc uruchomic na zadupiu, i zrobic checkouta jakiegos tam pliku w moim repozytorium [20:46] jacekowski: tak, o ile masz dostep do tego repo [20:46] BlessJah: ale jak? [20:46] skoro same pliki nie siedza w gicie [20:46] BlessJah: tylko jest problem, bo projekt jest duzy a kazdy task/issue ma byc na osobnej galezi, co teras? [20:46] xdudi: dokladnie tak samo [20:47] w dwoch krokach, najpier normalny klon gita, ktory ci da symlinki do nieistniejacych plikow w .git/annex/objects [20:47] a potem annexem pobierasz te pliki, ktore chcesz [20:48] jacekowski: przy duzym projekcie i duzej liczbie deweloperow, narzut z kopiowania calego projektu do kolejnego brancha itd, sprawi ze taka praca bedzie kompletnie nie efektywna [20:48] xdudi: ale to nie nie robi kopii [20:49] xdudi: svn sie skaluje nawet-nawet, zalezy jak duzy projekt i ilu devow [20:49] jacekowski: a praca na golym trunku jest tez bez sensu bo jak wprowadzicie 20 funkcjonalnosci a 3 maja przejsc do stable, to jak to pomergujesz? to zajmie tygodnie... [20:49] xdudi: to jest CoW [20:49] xdudi: dokladnie tak samo jak w GIT [20:49] xdudi: robisz kilka branchy ktore sie tworza w mniej niz sekunde (bo to tylko modyfikacja metadanych) [20:49] jacekowski: zeby robic jak w gicie, musisz miec 20 branchy... [20:49] xdudi: no i jest to zaden problem [20:50] xdudi: robisz branche a potem merge [20:50] jacekowski: metadane sa na serwerze, a na kliencie sa pliki i nie zajmuje to mniej niz sekunde [20:50] jacekowski: jak lokalnie przelaczac sie miedzy branchami? [20:51] BlessJah: nie da sie, kazdy branch to fork projektu [20:51] i ma inna sciezke [20:51] xdudi: da sie [20:51] tylko to kosztowne [20:51] czas i lacze zzera [20:51] svn switch [20:51] jacekowski: nope [20:51] checkoutujesz obok siebie branche [20:52] tez mozna [20:52] kazdy checkout 2x tyle co samo kod [20:52] zezre tyle samo miejsca i lacza co git [20:52] nie [20:52] git checkout nie zzera lacza [20:52] wlasnie ze nie ;] [20:52] ale musisz najpierw clone zrobic [20:52] musze [20:52] ktory sciagnie wszystko [20:53] a na svn checkout [20:53] jacekowski: http://git-scm.com/about/small-and-fast [20:53] rzuc okiem na te slupki :) [20:53] xdudi: takie same slupki tylko w druga strone sa na stronie svn'a [20:54] poza tym, nawet jesli, czy commit zajmuje 0.25s czy 1s, jest to zadna roznica [20:54] jacekowski: w jaki sposob chcesz miec archeologie (grzebanie w rewizjach) szybsza od gita na svnie? [20:55] jacekowski: moj ~/trunk/ zajmuje 2.2GiB, z czego ~/trunk/.svn to 805MiB [20:56] tylko ze git jest beznadziejnie wolny na duzych repozytoriach [20:56] jacekowski: git svn spakował mi to z połową historii do jakiegos 1.5GiB [20:57] jakies 100k commitow [20:57] i nie, nie jest wolny [20:57] http://git.661346.n2.nabble.com/Git-performance-results-on-a-large-repository-td7250867.html [20:58] ostatecznie facebook sie na mercuriala przeniosl [20:58] https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ [20:58] jacekowski: jaka skala wielkosci? [20:58] git status --porcelain --ignored 2>/dev/null|awk -f ~/.dotfiles.d/git.awk [20:59] kawalek mojego $PROMPT_COMMANDS, zlicza mi dodania, modyfikacje etc [20:59] moje wlasne repozytorium svn ktore mam w domu to jakies 500GB [20:59] a ile plikow? [20:59] wole nie wiedziec [20:59] cos kolo 100k [21:00] jacekowski: to teraz zrob te 20 galezi - issue per branch :) [21:00] jacekowski: zdjecia? filmy? [21:00] zobaczymy czy bedzie szybciej niz w gicie :) [21:00] zdjecia, programy, wszystko [21:00] ja trzymam ~50GiB w git-anneksie [21:00] filmy akurat nie [21:00] glownie iso i instalki roznych rzeczy [21:00] PORNOLE [21:01] jacekowski: ~/trunk ma 40k plikow, liczone bez .svn/* [21:01] git svn rzezil, bo kazda rewizje zaciagal po kolei, ale teraz dziala to dobrze [21:01] nie narzekam [21:02] http://stevehanov.ca/blog/index.php?id=50 [21:02] gjm: tez mozesz trzymac, mozesz nawet szyfrowanie wlaczyc [21:02] tu ktos narzeka na wydajnosc gita [21:03] pokazujesz mi linki z internetu [21:03] ja mam repozytorium 2GiB, 40k plikow, 100k rewizji, ktore po prostu dziala, a zliczanie zmodyfikowanych plikow mam wpiete do $PROMPT_COMMANDS [21:04] plus drugie, git-annex, z 50GiB duzych plikow, ktore syncuje miedzy dwoma lapkami i przenosnym dyskiem [21:09] jacekowski: no i moge zrobic git-blame w windzie [21:11] tortoise svn tez ma blame [21:11] w windzie takiej do jezdzenia [21:11] tam nie ma wifi [21:12] bo wczesniej sciagnales cale repozytorium [21:13] jacekowski: ale nie wyslesz commita via mail :P [21:13] xdudi: bardzo rzadko sie zdarza ze jestem w miejscu gdzie nie mam internetu [21:13] jacekowski: pi razy oko, 30% wiecej niz bym sciagal svn [21:13] jacekowski: oczywiscie przy normalnym, niepatologicznym uzyciu (nie wsadzamy duzych binarek do repo) [21:14] duze binarki to nie jest patologiczne uzycie [21:14] firmy takie jak pixar [21:14] obok kodu? jest [21:14] jacekowski: ale czasem zdarza sie, ze serwer ulega awarii badz jest modernizowany, i przez np kilka dni uzywa sie innych serwerow [21:14] tzn. pixar uzywa perforce do trzymania modeli 3d [21:14] mowimy o kodzie, czy o czym? [21:14] o wszystkim [21:14] to nic nie nadaje sie do wszystkiego [21:14] moze golebie pocztowe [21:14] microsd do nóżki i hurra [21:15] BlessJah: mam takiego w pracy co hoduje golebie i z nimi na wyscigi jezdzi [21:15] straty pakietow ma rzedu 5% [21:15] zmiana tematu [21:15] jacekowski: nic nie nadaje sie do wszystkiego, git nadaje sie do kodu doskonale [21:15] chyba ze masz duze repozytorium [21:16] git nadaje sie do duzego repozytorium kodu [21:16] nawet bardzo duzego [21:16] powyzej 10GB sie zaczynaja problemy [21:16] w koncu byl projektowany pod katem repo kernela linuxa [21:16] i nawet zaczyna wymiekac przy repo kernela [21:16] ile ma repo kernela? [21:17] dobre pytanie [21:17] sa dwa repo tak na prawde [21:17] jedno ze starymi rewizjami [21:17] i jedno z nowszymi [21:17] zeby nie bylo za duze bo git sobie nie dawal rady [21:17] jacekowski: 10GiB kodu to bardzo, bardzo duzo [21:17] jakby kernel linuxa chodzil pod svn, padlby juz dawno [21:17] zbyt duzo galezi, deweloperow i commitow [21:17] w dodatku brak decentralizacji... [21:18] wszystko musialoby stac na jednej maszynie [21:18] decentralizacja jest nikomu nie potrzebna [21:18] nie musialoby [21:18] mi jest potrzebna [21:18] svn mozna na klastrze bez problemu [21:18] i czekalbys 30 minut na wrzucenie commita [21:18] nie [21:19] xdudi: a do czego ci niby decentralizacja? [21:20] ostatecznie jest tylko jeden branch/repo z ktorego sie buduje gotowy produkt [21:20] jacekowski: by moc glowny serwer wylaczyc i zmodernizowac, zeby ludzie mogli uzywac zastepczego [21:20] xdudi: to da sie z svn [21:20] jacekowski: praca lokalna i lokalny git blame [21:20] ale jest to duzo trudniejsze, poco torturowac sie svnem na sile :) [21:21] po co sie torturowac gitem na sile [21:21] tym masz chyba syndrom sztokholmski [21:21] ty* [21:21] masz racje, release robi sie z jednej galezi [21:21] jacekowski: svn ma jedna niewatpliwa zalete: jest prosty do nauczenia [21:22] ale svn utrudnia strasznie development [21:22] jacekowski: przy duzym projekcie trzeba wielu ludzi, ludzi ogarnietych jest ograniczona ilosc, wiec w pewnym momencie zatrudnia sie coraz slabszych ludzi