instalace distribuci do virtualu 2017 - par postrehu

14.3.2017 18:37 | Přečteno: 1633× | distribuce ve virtualu | poslední úprava: 17.3.2017 10:36

jen tak mozna by se nekomu mohlo hodit, zkousel jsem nainstalovat na mym macbooku pro par distribuci, vzdy nejdrive do Parallels, kdyz byl problem pak do Vmware pak do Virtualboxu, za uspesnou jsem povazoval kdyz instalace probehla v pohode vcetne u Parallels Parallels Tools, u Vmware Vmware Tools a Virtualboxu Virtualbox Additions, par distribuci jsem zkusil i naostro na fyzickem hw pres refind ale zkusenosti nebyly moc pozitivni (zkusil jsem opensuse tumbleweed a ubuntu), proste se mi ten dual boot nejak rozdrbal asi problem s uefi a refind neni tak vsemocny aby si po priinstalaci dalsiho OS sam ocichal partitions a pridal automaticky jednotlive polozky do sveho boot menu, to uz jsem mel v minulosti lepsi zkusenosti s reflt

nazory prosteho klikace

opensuse tumbleweed – udelala na mne nejvetsi dojem, KDE ma klikatka pres yast na snad uplne vsechny konfiguracni nastaveni, one click install pres software.opensuse.org je navykovej, suse open build service na mne take udelala dojem, pri ostre instalaci ale nerozpoznala moji wifi broadcom, ale nejak jsem pak metodou pokus omyl doinstaloval ruzne bc* broadcom wifi wireless wlan balicky a casem to "samo"zacalo chodit, vubec netusim jestli pres Network Manager nebo jiny nastroj na spravu pripojeni, byl jsem v tom dezorientovan, prilis mnoho nastroju, prilis mnoho cest, prilis mnoho moznosti

suse linux enterprise desktop – prekvapive mnohem vetsi problemy pri instalaci nez u opensuse tumbleweed

centos 6.x – dojem rock solid, vsechno bez nejmensich problemu

openbsd, netbsd, dragonfly bsd – brutal, ani jsem si netuk, defaultni instalace je bud uplne bez X ek – openbsd, nebo s nejakym obskurnim WM ve kterym krome terminalu nebylo vubec nic, ani spravce softwaru kterym bych si neco pridal – netbsd, dragon fly jsem ani nenainstaloval

freebsd – do pouzitelneho stadia jsem to dostal az pres navod na youtube, jinak defaultni instalace mne ani nehodila do X ek

pc-bsd, nyni trueos – user friendly, nebe a dudy proti shora zminenym *bsd, ovsem Tools(Additions) pro ne ve VMs nejsou nebo se mi nepodarilo rozchodit

slackware – brutal, uz instalace pro mne porod ale dal jsem to vcetne manualniho rozdeleni virtualniho disku, proste co si sam neudelas to nemas, X ka bez spravce softwaru nebo jsem nepochopil kde a jak se instaluji Apps ?, Tools(Additions) pro ne ve VMs nejsou nebo se mi nepodarilo rozchodit

salix – pokus o vice user friendly slackware, nainstaloval jsem krome Tools(Additions) pro ne ve VMs nejsou nebo se mi nepodarilo rozchodit, jinak ve spravci softwaru malo balicku

Zenwalk – dtto jako Salix dalsi pokus o user friendly slackware, Tools(Additions) pro ne ve VMs nejsou nebo se mi nepodarilo rozchodit

Chakra linux – povedlo se, opet snaha o user friendly slackware, malo balicku, Tools(Additions) pro ne ve VMs nejsou nebo se mi nepodarilo rozchodit

Wifislax – dtto pokud si dobre pamatuji ale jen live dvd, myslim ze se neinstaluje ale jen spousti ruzne forensic tools rovnou z live bootu (obdoba kali linuxu ktery se ale instaluje)

Vector linux – ani jsem nenainstaloval jestli si dobre pamatuji, jinak dalsi pokus se slackware

debian stable, testing – distribuce ktera mi nejvice prirostla k srdci, je dost konzervativni abych se i neco naucil pres rucni konfiguraci a zaroven ma i nejake ty gui klikatka co usnadnuji spravu, dobra rovnovaha mezi obojim

kubuntu, ubuntu, xubuntu, linux mint – vsechno out of the box vcetne Tools(Additions) pro ne ve VMs, oproti debianu kde jsem *.deb shnale po celym netu vsude mozne tak tady pres ppa launchpad jednodussi najit co potrebuji

antergos – distribuce ktera mne nejvice prekvapila nebot mi jako nezkusenemu otevrela svet ARCHu a AURu – udelala na mne dojem, nejvetsi pocet aplikaci ze vsech dister pres yaourt, nehrajou si na patenty

fedora – problem s instalaci ver.25, musel jsem zvolit 24, celkove na mne pusobila jako "nedotazena"furt jsem mel pocit ze neco fungovat nebude

ghostbsd – druha nejvic user friendly *bsd po pc-bsd (trueos)

mageia, mandriva – celkem prijemny dojem asi spis pro zacatecniky jako ja, vsechno jsem rozchodil

oracle linux – rozchodil jsem ale pouzivat bych to nechtel, nemel jsem pocit takove funcnosti jako u CentOS 6.x

mx mepis antix – rozchodil jsem, ale radeji bych bral debian

slax, knoppix, wifislax – neplnohodnotne distribuce na plnou instalaci na hdd, hodi se jako boot live usb tam ma knoppix live dvd na usb flashdisku vubec nejlepsi detekci hw ze vsech dister co jsem zkousel na fyzickem hw, slax ma malo balicku mel by prejit na debian based

slacko puppy – nainstaloval jsem, ale clovek je odkazan co pro nej komunita vytvori za balicky *.pet *.pup pokud se je nenauci vytvaret si rucne sam je druhej kdyz neco chce

sabayon – pro mne jedina moznost jak nahlednout do sveta gentoo, rozchodil jsem ale nevedel jak dal, jak se tam instaluji apps ?portage emerge ebuilds .. musel bych se hodne ucit, holt distro pro velky kluky

Solaris, OpenIndiana – jen jsem to dostal do Xek, dal jsem se nehnul, Tools(Additions) pro ne ve VMs nejsou nebo se mi nepodarilo rozchodit, pocit ze vubec nejsou aplikace nebo je jich ve srovnani s linuxem strasne malo

elementary – rozchodil jsem vse, pocit user friendliness asi na urovni mageia (openmandriva)

zorin – vse ok, takovy nenapadny cerny kun, mel jsem dojem ze to bych asi zvladnul pouzivat

pclinuxos – vse ok, pocit zhruba jako u elementary, zorinu a magei (openmandrive)

archbang, bridge linux – nepovedlo se mi vubec nainstalovat,

manjaro – dokazal jsem nainstalovat, smutek ze neni AUR jen vlastni repo manjara kde je toho oproti AURu hodne malo, pry AUR se da manulane zapnout jak a kde ?

kanotix, kali linux (byvaly BackTrack)– silne pod vlivem debianu, vsechno ok, Kali - hodne nastroju pro penetracni testy, hacking

suma sumarum – asi neco je na tom co clovek zacal pouzivat jako prvni na fyzickem zeleze, u mne to byl debian takze mi pripada k mym schopnostem, moznostem a cilum (jen nainstalovat, lehce upravit a pouzivat) jako nejblizsi, libi se mi jista konzervativnost a vybalancovavani mezi klikatky a rucni konfiguraci

pokud bych byl v budoucnu ultra linej a chtel vsechno jen naklikat a pouzivat tak bych asi zkusil znovu ten opensuse tumbleweed, xBuntu a Mint bych take snesl ale mam u nich pocit ze si to nejak zije "vlastnim zivotem"a ja musim akceptovat jak je to "nastaveny uz z tovarny"i kdyz mozna prehanim, jsou to user friendly distra ale wifi broadcom ani po zaskrtnuti non-free pri instalaci proste out of the box nechodila a prave dabel je skryt v detailech, tohle beru u techto dister jako fail a pusobi to na mne negativnim dojmem nedodelku, nastavit jen zaklad a "jit od toho" at si se zbytkem kazdej poradi ...

a pokud bych rad riskoval ze neco vlastni neschopnosti zkazim ale chci mit pristup k nejvetsimu zdroji software bez rucniho pridavani repozitaru, ppas, shaneni kde se jaky *deb *rpm vali na netu tak antergos

snad si z toho nekdo muze neco vzit, treba ze jsem neschopa, proste kazdymu distru jsem venoval jen jeden pokus a chvili casu a proste bud to slo vsechno out of the box na 1 kliknuti vcetne Tools(Additions) pro ne ve VMs nebo to hned slo z disku

uplne jina liga by pak byla instalovat tohle vsechno na ruzny fyzicky hw a divat se co chodi rovnou a co ne, na to jsem nemel chut, pro me potreby staci VMs, aspon jsem odstinen od problemu s rozchazovanim hw        

Komentáře

[Marián Kyral]

nazory prosteho klikace

Názor prostého čtenáře: textu chybí jakékoli členění do celků, zvýraznění nadpisů, odrážek a diakritika. Strašně špatně se to čte

[David Indra]

Není to dokonalý, ale pro mě je super, že někdo vůbec něco takovýho sepsal. Díky autorovi :)

[vencour]

Nějak mi uniká účel takového testování začátečníkem? Za druhé pokud jste to dělal aspoň trochu poctivě a důkladně, tak to muselo zabrat moře času.

[Michal Kubeček]

Kdyby to bylo napsané trochu čitelněji a k jednotlivým distribucím (kterých by klidně mohlo být mnohem méně) bylo trochu víc postřehů, mohl by takový přehled mít docela dobrý smysl. Pro zkušeného uživatele je řada věcí natolik samozřejmá, že se nedokáže vžít do role začátečníka a představit si, jak instalátor působí na něj.

Bohužel i drtivá většina článků na téma "recenze distribuce D verze X.Y" vypadá tak, že se projde instalace (se screenshoty), spustí defaultní desktopové prostředí, udělá dalších pár screenshotů, napíšou verze pár vybraných balíčků a je vymalováno. Nevzpomínám si, jestli jsem vůbec někdy viděl recenzi distribuce napsanou třeba po půl roce (nebo aspoň měsíci) každodenního používání.

[fotonové torpédo]

Bohužel i drtivá většina článků na téma "recenze distribuce D verze X.Y" vypadá tak, že se projde instalace (se screenshoty), spustí defaultní desktopové prostředí, udělá dalších pár screenshotů, napíšou verze pár vybraných balíčků a je vymalováno.

Což do značné míry vyplývá z toho, že, zvláště z pohledu začíátečníka a BFU, se distribuce od sebe liší především instalátorem, základním grafickým prostředím a verzí programů.

[trevor12]

treba ja jako bfu nechapu proc je freebsd instalace tak nepratelska .. musel jsem pouzit tento navod

https://www.youtube.com/watch?v=X1AhdDlVnx4

zhruba od 4:50 min

[rum]

Protoze neni pro debily, kteri nepochopi, ze *BSD je pro pokrocile...

[Vykook]

No po asi 10 letech je můj, čistě osobní, poznatek ten, že není moc důvodů instalovat linux s GUI, protože prakticky vše rozjedu přes Xka co se dají do OS X normálně nainstalovat. Navíc je k dispozici vcelku geniální balíčkovací systém(škoda, že port pro Linux asi umřel) homebrew. Co ovšem virtualizuju je docker, protože ten samozřejmě na macu nativně nejede a poslední dobou na to používám naportovanou FreeBSD virtualizaci xhyve. Není to samozřejmě úplně dospělej projekt(to ostatně zatím není ani původní bhyve), ale pro tohle použití stačí a navíc skvěle funguje s docker-machine.

[dsjkxk]

Homebrew pro linux umrel, ptz je to znouzecnost. Zkus nekdy macports.org, ktery ma novejsi jak binarky, tak flagovatelne sources, podporuje vice verzi nainstalovaneho sw zaroven, dokaze po sobe uklidit a neprepisuje systemove binarky.

[Vykook]

Tys ten homebrew moc nepoužíval, co? Víc verzí jednoho balíčku samozřejmě podporuje, dokonce při aktulizaci tam defaultně ty starší nechává(odlinkovaný). Uklidit po sobě taky dokáže(ostatně, vše se děje v jednom adresáři) a systémové binárky nepřepisuje už vůbec(protože se akorát linkuje do /usr/local/bin, kde v čistém OS X stejně nic není). Macports jsem krátce používal před cca 3 lety a byla to proti tomu poměrně nepřehledná slabota. O tom, že má novější binárky vcelku pochybuju, ale pokud ano, tak je mi to stejně v postatě jedno. nejsem "honič verzí"

[dsjkxk]

Priznavam, dlouho jsem to nepouzival. Je dobre vedet, ze se Homebrew za tech par let zlepsil. Az zkopiruji macports uplne, tak to mozna zkusim znova.

[Vykook]

On to tak dělá od začátku. Všechno cpe do /usr/local/Cellar/jmenoBaliku/verze/ . Toho se nejspíš nedočkáš, protože snahou to je právě dělat lépe(no dobře, řekněme jinak, ať nerozjedem flame ) než macports.

[dsjkxk]

Ale co delaji lepe? Porad me pripada, ze se jen snazi neco delat lepe, ale ve vysledku jen dotahuji macports.

[Vykook]

Čoveče, sice ani nevíš, že homebrew podporuje víc verzí balíčku od samého prvopočátku, ale jisto jistě víš, že se teprve dotahuje na macports... Co dělají lépe? To je dost subjektivní, ale například používaj knihovny co jsou už v systému a necpou ti duplicity(namátkový příklad ncurses). Použití githubu jako repozitáře, takže na přidání balíčku stačí normálni pull request. V neposlední řadě jejich triviální struktura, která je v postatě jen z ./configure && make && make install. Je aktuálnější(teď jsem namátkově koukal na vim, mc a node), což tak nějak plyne z toho předchozího. A hlavně po instalaci ukáže v shellu pivo.

[hydrandt]

No jo, pokud ti nevadi pouzivat nesvobodny software :-P

[Vykook]

Ale jo, vadí. Jen se dneska GPL a Affero GPL dost špatně vyhejbá. :-/

Proto používáš raději proprietární macOS.

[snajpa]

OpenIndiana na desktopu umrela a v podstate se moc neudrzuje (nepribyvaji moc ani drivery tim smerem v Illumosu). Kde ma Illumos smysl jsou servery, pokud se bude vyvijet ten ekosystem smerem, kudy jde, mohl by byt solidni nahradnou za linux na masinach s vice, jak 128 GB RAM.
Uz ted v urcitych use-cases muze byt, s LX branded zonami je to o to zajimavejsi a jeste lepsi je fakt, ze se aktivne pracuje na podpore cgroups&namespaces interfacu v LX branded zonach.
Tj. Illumos (konkretne SmartOS) bude moct poustet aj hipsteriny typu Docker a az se to stane, Linux uvidim tak na notebooku a mensim hw (embedded).

[Bedňa]

mx mepis antix – rozchodil jsem, ale radeji bych bral debian

Mepis umrel, na jeho základoch vznikol antiX a MX je viac komunitná záležitosť založená na antiXe, kde prejde skoro všetko do upstreamu.

Samotný antiX je Debian rovnaký aký kedy pred tým, bez vymožeností ako systemd a podobne, ale je moderný a drží krok s Debianom.

Sám udržujem svoju odnož antiXu LegacyIce, pretože časom všetko prebublalo do upstreamu (až na maličkosti), ide už len o grafickú a ergonometrickú úpravu distra.

Používá už antiX něco lepšího, než SysVinit? (Třeba OpenRC.)

[Bedňa]

OpenRC už v antiXe je, ale defaultne sa nepoužíva.

[pc2005]

Slackware je brutal? Vždyť to je jen tak 20 dialogů . Aspoň jsi nemusel jako já dát na disk ventilátor (jako když jsem poprvé instaloval slacka ... proč jsem měl disk mimo skříň to si fakt už nepamatuju ).

[trevor12]

jinak asi chapu jak muze vznikat tolik dister, staci vzit nejake distro *.iso a asi podobne jako v tomhle navodu

https://itvision.altervista.org/aptosid-remastering-how-to.html

si udelat custom distro treba v tomto pripade pro http://distrowatch.com/table.php?distribution=siduction (navod je pro aptosid, predchudce sidux resp. siduction)

podobne to asi pujde kdyz si vezmu za zaklad jine distro

[otasomil]

Zdravim

Tak to jste opravdu velky nadsenec. Videt ze mate spoustu volneho casu. Ja zustal u dister zalozenych na Debianu. Nemam uz cas ani sil poznavat dalsi i kdyz me laka zkusit i jina distra. A do virtualu no teda spis kontejneru LXC taky neco na Debianu. U LXC me nadchla rychlost operaci a ze vsechno funguje hned. Z virtualizace na desktopu vyuzivam dnes uz jen Virtualbox.

[trevor12]

ja bych si pral aby distribuce prestaly respektovat gpl lgpl bsd ... proste aby v nich byly i proprietarni ovladace a vsechno fungovalo out of the box hned po bootu (instalaci) zejm. wifi protoze bez connectivity je clovek docela druhej .. kdyz to umi knoppix nevidim duvod proc jine distirbuce delaj tanecky a clovek musi zakliknout pri instalaci nonfree balicky, navic stejne to pak casto nechodi .. pri bootu knoppixu mi chodi vsechno a vsechny hdd (usb) jsou rovnou r/w

[Vykook]

V případě respektování BSD licence právě tohle všechno odpadá. Můžeš s tím dělat prakticky cokoli.

[Bedňa]

Lenže licencie sú od toho aby sa dodržiavali.

Pretože GPL je taká aká je, udržiava komunitu ktorá dobrovoľne vyvíja kopec softvéru. Zato so záchodou licenciou BSD si môžeš vytrieť prdel a rovnako vyzerá aj tá ich hipsterská "komunita".

[Vykook]

Když se rozhlídnu tady kolem, tak zlatá BSD komunita a zlatá BSD licence.

[okbob]

Kde je BSD, a kde je Linux? Dobrovolně do BSD projektů zpětně přispívá minimum firem - ještě jsou to většinou bývalí vývojáři.

[snajpa]

Nastesti. BSD zacina byt paradni alternativa na servery. Tim myslim na servery, ne hracky (a ne, Linux tam neni vhodny).

[⧠ A = 0]

Můžeš být konkrétní? BSD je dost široký pojem.

[Vykook]

Bohatě stačí, že čisté FreeBSD má aspoň jeden pořádnej moderní FS v produkční kvalitě.

[snajpa]

Toz FreeBSD - a z nej vychazi spousta dalsich distribuci, proto jsem nenapsal FreeBSD konkretne.

[Bedňa]

Nastesti. BSD zacina byt paradni alternativa na servery. Tim myslim na servery, ne hracky (a ne, Linux tam neni vhodny).

O aké štúdie sa opieraš. Čo v Linuxe nejde naškálovať?

[Michal Kubeček]

Nekrmit, prosím.

[Bedňa]

Sami na stránkach FreeBSD uvádzajú, že výkon FreeBSD môže byť väčší, rovnaký, alebo horší ako na Linuxe, čo ma moc nepresvedčilo na prechod.

BSD systems, in particular FreeBSD, can have notably higher performance than Linux. But this is not across the board. In many cases, there is little or no difference in performance. In some cases, Linux may perform better than FreeBSD.

Linux je škálovateľný masakrálne a strávil som s tým pár mesiacov testov, takže by sa dalo pochybovať, či by vôbec v nejakej úlohe BSD podal lepší výkon.

[Michal Kubeček]

Nejde mi o porovnání Linuxu a FreeBSD, ale o to, že reagujete na tradiční flamebait člověka, který se sem chodí bavit tím, že v diskusi utrousí nějaké podobné "moudro" a když se někdo nachytá a zeptá se, zda to může něčím podložit, důležitě sdělí, že všechny zajímavé technologie v Linuxu jsou vlastně jen nepovedené pokusy o napodobeninu skvělých a nedostižných technologií Solarisu. Na dotaz, proč ho tedy Google, Facebook, SAP, banky, automobilky a další používají pro své hodně velké a hodně kritické systémy, nám pak vysvětlí, že je to jen a pouze kvůli ceně, rozhodně ne kvůli technickým měřítkům, protože tam Linux zoufale zaostává.

Tenhle scénář už se tu zopakoval tolikrát, že zbývá jen jediná rada: nekrmit.

[Bedňa]

Nedalo sa nevšimnúť, že si Snajpa občasne rád kopne do Linuxu, len neviem či som prehliadol, alebo sa nezúčastnil (možno zabudol) nejakej diskusie kde padli relevantné informácie.

Snajpu beriem takého aký je, hoci toto bol asi fakt taký výkrik do tmy, keď pokiaľ viem stavia (stavalo?) VPSfree na Linuxe.

[snajpa]

Co ti povim, jsem z toho zoufaly. Ano, zatim jedeme na Linuxu. Ale co je dneska tak, zitra muze byt jinak, protoze se landscape kontejneru zmenil s politikou firmy, co ty kontejnery pro linux vyviji a to pro nas vubec ne k lepsimu. Dopadlo to tak, ze si budeme muset delat nejaky jaderny vyvoj - a kdyz jsme dosli do tohohle bodu, mame jeste rok na migraci na dalsi reseni a na platforme, kde nesmrdi CPU scheduler, memory alokator, performance monitoring a on-disk data management subsystem, se zacina dat provozovat nativne binarky pro Linux, tak to nema ten Linux u nas vubec jisty.

Ja nevim, co po mne mistr Kubecek chce, ale nevidel jsem, ze by s tim neco delal, let alone ze by vubec pochopil, o cem tocim. A jasne, ze si kopnu, protoze si musim delat srandu ze systemu, kde se radsi nez na funkcnost bude dupat na GPL modlu a budeme se bit do prsou, jak mame uzasny vyvojovy model, ale uz si neprizname, ze ma poradne mezery.

V realu se pobavme o Linuxove masine, kde si pustim upstreamovy kernel bez pridavku se "smradlavou" licenci, pobezi tam 100 kontejneru kazdy s prumernou Rss okolo 1 GB a cca 1k procesy, s nejruznejsim typem zateze. Dejme pristup do tech kontejneru 100 lidem a rekneme jim, ze muzou verit tomu jadru. Nainstalujme to na stroj s 2 sockety, 20 jadry s HT a 256 GB RAM per socket, tj. 512 GB RAM. Pouzijme 2 SSD disky a dejme tomu 16 rotacnich 2.5" SASu.

Takze. Jak nakonfigurujete storage pro tech 100 kontejneru? Ma tam byt treba, rekneme 30 MySQL instanci a zadna z nich se nebude flakat. Do toho kazdych par hodin 15 kontejneru dela divoky rsync pres 2 TB dat. Do toho bezi 5 instanci bittorrentu.

Otazka pro fajnsmekry: jaky maximalni uptime mi dovoli upstream kernel, pokud pouziju user namespace jako jedinou izolaci, protoze vic dostupneho neni? Ano, tim myslim potrebu rebootu kvuli update jadra. Kez by fungovalo CRIU na vsechny a ne jenom polovinu z tech 100 kontejneru.

Bonusova otazka: jak dlouho to vydrzi bezet, nez se to slozi? Nez se ta masina zakucka, ve smyslu prestane fungovat NFS, naroste latence na siti, zadusi se disky, nebo se objevi kswapd na 100% jadra a cely system se zaseka?

[Bedňa]

Podľa mňa na to ideš zle. Vadí ti niekoľko vecí, teda čítal som aj to vlákno s Michalom a je ich asi tak päť.

Škálovanie je nikdy nekončiaci proces, dvôležité je aby si si ho zdokumentoval. Distribučný "config" je vždy len obecný aby viac menej išlo všetko OK, je nepoužiteľný do vyšpičkovanej prevádzky. Chce to hodiny si všetko odskúšať a určite vygoogliš upravený pre rôzne úlohy.

Začal by som s tým, že si vyberiem prvý problém ktorý ma trápi, skúsim Goggle, či ide o obecný problém a budem si to spisovať. Niekedy má človek zlozvyky ktoré robí automaticky, pretože to niekto doporučuje, alebo si na ne zvykol.

Poctivo si zpisuj ako si ktorý problém riešil, ideálne všetky kroky od holého systému a hoď si to na nejaký verzovací systém, aby sa mohol vŕtať v histórií. Keď budeš mať postup ako si čo robil, ľahko si splácaš skript na replikáciu systému.

Sleduj všetky parametre ktoré ťa trápia, buď nejakým nástrojom, alebo si proste zas napíš skript, časom nebude problém identifikovať skutočný problém.

Keď budeš mať dostatok informácií, kľudne oslov niektorého vývojára problémovej časti systému a odovzdaj mu informácie. Nieje nič lepšie ako si dať softvér napísať zadarmo. Proces ukceptácie do main line nemusí byť hneď, ale zatiaľ budeš mať svoj vlastný patch a keď podáš presvedčivé testy, tak tomu určite pomôžeš. Áno takto funguje slobodný kód. Prípadne sa dozvieš čo robíš zle a ako problém riešiť.

S vývojármi sa treba snažiť skontaktovať "osobne", proste hodenie problému do "bugzilly" sa nemusí nikto chytiť, pretože ho problém nezaujme. Mail, IRC, jeho blog ... Napíš kľudne o tom článok a podsuň mu link. Na Linuxe robí dosť českých vývojárov, to by mohlo pomôcť, hoci pri slobodnom softvéri sa na nejaké národné veci nehrá, chceme tu proste spraviť lepšie miesto na zemi

A keď to všetko absolvuješ, pôjdeš zas odznovu, to je proste vývoj

Kľudne by som použil viacero nástrojov na automatickú analýzu kódu, jednoriadkových opráv je veľa a niekedy kvôli tomu problém hnije v bugzille roky.

Neverím, fakt vôbec neverím, že by si nejaké FreeBSD zapol a vetko by šlo out of the box. Môžeš po dlhej práci na migrácií naraziť na ďaleko väčšie problémy a určite aj narazíš.

[snajpa]

No, vis, ja jsem se na nejaky server prihlasil teprv vcera a cucam si z prstu stylem jedna pani povidala (aneb, nepovidej, tyhle veci musi delat kazdej soudnej admin OSS systemu, Linux nelinux).

Neverím, fakt vôbec neverím, že by si nejaké FreeBSD zapol a vetko by šlo out of the box. Môžeš po dlhej práci na migrácií naraziť na ďaleko väčšie problémy a určite aj narazíš.

Tak to mi vkladas do ust neco, co jsem ani nerekl.

[Bedňa]

Vyššie aj nižšie si popísal problémy, tak vyber jeden a napíš kde to v Linuxe troskotá. Fakt len jeden a ako si ho riešil.

[snajpa]

Jsi dost sikovny, abys zvladl googlit sam, takze ti povim, co mas googlit a uzij si to, ja uz tim znova ztracet cas nebudu - fragmentace SLABu je konkretni problem, ktery nemam jak vyresit, i kdyby ho upstream nekdy defrag slabu zamergoval, nemame jak jet na upstream kernelu kvuli user name space, kdyz je v nem nekolik CVE behem par mesicu - je to prilis slaba izolace. @ SLAB - ZFS potrebuje pro svoje buffery kvuli dynamicke velikosti bloku a zachovani nejakyho vykonu linearni buffery az do 128k. Na FreeBSD to neni problem, na Illumosu uz vubec (od tech lidi btw SLAB prisel anyway), na Linuxu to problem po par tydnech az mesicich uptime je 100%. Projevi se to kswapd na 100% a lagujicim systemem po vsech strankach, protoze se reclaimuje pamet do aleluja. A pogoogli si, jak je na tom linux, kdyz dochazi pamet obecne. Nenut mne svoji potrebou mi neco ukazat ztracet muj cas, ja uz jsem tim casu zabil dost.

[Bedňa]

Sorry za lagy, bol som v reálnom živote :)

Verím, že v tvojom konkrétnom prípade môžeš mať problém, len nevidím tu odkaz na config ako si to riešil, s kým si to riešil a tú históriu na ktorú som poukzoval.

Sorry toto sú len náreky ktoré nemajú žiadnu cenu. To je potom lepší aj MS Win, keď to nijak nepodložíš.

[snajpa]

Aktualne se treba strasne smeju nad timhle.

One typical mechanism that triggers slab defragmentation on my systems is the daily run of

updatedb

Oh parada. Takze tohle se resi v upstreamu - a nam tam takovych userspaces bezi klidne 120.

[Bedňa]

Podľa odkazu sa na dosť sere. Prebrané je to pokiaľ viem zo Solarisu, tak neviem na čo si sťažuješ

Keď to chceš riešiť, tak to spíš a pošli niekomu z jadrákov ktorých poznáš a možno sa to stane témov číslo jedna.

Fakt neverím tomu, že keby bolo viac ľudí ktorí si na to sťažujú, že sa to riešiť nebude. Minimálne by skúsil túto tému otvoriť na Reddite a podať tam nejaké testy.

[snajpa]

A nepratelskost vuci open-source, ale ne fasisticko-GPL-kompatibilni CDDL licenci to vyresi jak? Ze ZFS nemuze rovnou pouzivat ftrace; ze se obecne na Linux musi pasovat z boku; a co kdybych chtel DTrace?

[Bedňa]

Jasne nápady z licencií hodnotných hajzovému papiru sa zas musia prepísať, pretože tu máme komunitu, ktorá chce spraviť svet lepším miestom na zemi. No a zamedziť dookola vymášľaniu klesa, čo BSD a podobné licencie podporujú.

Neriešia patenty, neriešia uzavretie kódu, neriešia žiadnu budúcnosť. To natrafíš za pár rokov na nepodporovaný HW a že prečo? Lebo "closet" záchodová licencia.

[snajpa]

A ktera komunita prosim resi storage? A vtipkovani typu BTRFS neprojde ;)

[snajpa]

A btw, zatim co se ta tvoje komunita zabyva napodobovanim ZFS, se OpenZFS hybe dal a sbira momentum nad vice ruznymi kernely ;)

[Bedňa]

Slobodný kód je vyhliadka do budúcnosti aby si na ňom časom nezačal niekto kutiť vlastné uzavreté riešenie ako na BSD.

Za celé vlákno čo som ťa žiadal o zdokumentovaný postup jednej jedinej chyby, si my neposkytol žiadnu informáciu.

Pretože ťa mám rád a nebudem to hlásiť na centrálu GNU, tak to nabudúce skús a potom ti budeme môcť pomôcť s tvojim problémom, ktorý je možno už vyriešený, ale nevieme či vôbec existuje.

[smazáno]

Fakt neverím tomu, že keby bolo viac ľudí ktorí si na to sťažujú, že sa to riešiť nebude.

I want whatever drugs you are having!

[Bedňa]

Už som písal vyššie, že to nejde samo od seba, ale treba tomu venovať čas a energiu.

Možno mám väčší potenciál niekoho ukecať, alebo sa s niekym spriateliť, ale proste tá cesta funguje.

[smazáno]

Tyvole, nejen extremne pozitivni mysleni/naivita ale taky totalni sebevedomy/namyslenost - I want whatever drugs you are having!!

Ale vazne, v Linuxu (a jinem open-source softu) jsou zavazne bugy 10+ let, na ktere si stezuji zastupy uzivatelu a totalne se na ne, s prominutim, sere - jsou na ne dokonce i verejne patche, ale maintaineri prece vedi nejlip! Vem si co bylo potreba a jak to dlouho to trvalo aby se pred lety aspon trochu napravila situace kolem gnu libc!

To ze to nechapes je jen tvoje zabednenost.

[Bedňa]

Mám tu aj jeden blog o marketingu v slobodnom softvéri a viem, že sa veci neriešia sami od seba.

Keď si začneme spolu viac písať, myslíš si že ťa neukecám aby si v tvojom kóde niečo zmenil, alebo aby si mi tam niečo nedoplnil?

Vieš píšem bežnú frázu, čo som tu už aj niekoľko krát spomínal, že neovládam anglickú gramatiku a vývojár mi ešte odpíše, že tvoja gramatika je OK.

Proste žijeme asi v úplne inom svete, nikto ti proste nebude opravovať bugy pretože si to ty napísal, bude opravovať bugy na tom čo chce. To že je to dvôležité, o tom ho ale ty musíš presvedčiť ty.

[smazáno]

Asi to zacinam chapat ... ten tvuj slunickovy pristup vychazi z toho ze si na FLOSS nehnul ani prstem.

[pc2005]

Linuxu (a jinem open-source softu) jsou zavazne bugy 10+ let

I v kernelu? Jaké :-O.

[smazáno]

Uz jdou usb disky pouzivat bez zasekani celyho desktopu aniz by uzivatel musel resit nejake magicke hodnoty? :-O

[Aleš Kapica]

Problém s připojením externích disků přes USB jsem naposledy řešil u jader řady 2.6 což je bratru víc jak deset let zpátky. Jak tak na to koukám, podle toho cos napsal, tvoje představa o Linuxu odpovídá té době. Jenže se nepíše rok 2007 ale 2017 a za tu dobu se dost věcí změnilo. A z mého pohledu ty nejzásadnější změny proběhly loni.

[smazáno]

Zkus na ten disk take nahravat nejake data - naposledy se mi takto zasekal cely desktop v Ubuntu 16.04, kdyz jsem pripravoval instalacku FreeBSD.

[Aleš Kapica]

Tak zkus pro změnu používat nějakou nromální distribuci. Nepamatuji si, že by mi bylo někdy zasekalo desktop kopírování dat na USB disk.

[smazáno]

opravdu za to nemuze ubuntu :) https://lwn.net/Articles/572911/

[Aleš Kapica]

Ježíš, už jsem to přeci jednou napsal - píšeme rok 2017. Poslední reakce v té diskuzi je dva roky stará.

[smazáno]

Linus v roce 2013 tvrdi "je to fixnuty, tady je patch". V roce 2015 mame u toho stejneho clanku komentar od nejakeho chudaka "stale na ten problem narazim, stravil jsem na tom more casu, nakonec jsem prisel na tohle - tady je muj workaround". V roce 2017 se ten stejny bug projevuje minimalne na debianu a ubuntu. Zadny problem nemame.

[Aleš Kapica]

Já používám Debian a na žádný podobný problém jsem nenarazil.

[pc2005]

No já mám jenom flashdisky, čtečku a usb2-sata adaptér, ale nějakýho výraznýho lagování jsem si nevšiml. Jediný storage, co mě lagovaly, byly disketovka při nestandardních podmínkách (BIOS jí na mým kompu oficiálně nepodporuje a měl jsem jí namuxovanou na parportu), když jsem jí vyndal za běhu (ale i tak zápis kdysi lagoval v linuxu mnohem míň než na win98). Druhej byla DDS/DAT mechanika, ale na ten kód IMO nikdo nešáhl tak od roku kdy se začal rušit global ioctl lock .

Každopádně nějakej lag mě nepřijde jako závažný problém.

[smazáno]

Je to znamy problem - viz ten clanek na lwn.

Každopádně nějakej lag mě nepřijde jako závažný problém.

To je dobry pristup, aspon je pak clovek v klidu.

[pc2005]

No problém to je, ale slovem závažný bych čekal něco jako rootkit.

[Aleš Kapica]

Opravdu zajímavé, jak ti co začnou ztrácet půdu pod nohama začínají ty druhé obviňovat z namyšlenosti.

V Linuxu jsou bugy, tak jako v jiných systémech. Rozdíl je pouze v tom, že je na ně mnohem snazší narazit, protože je kód otevřený, a také je mnohem větší pravděpodobnost, že na ně někdo najde řešení, které bude lepší než u jiných OS.

Pokud jde o kernelové maintainery. Každý projekt sebou nese nějakou byrokracii. A chápu že nění snadné se jí prokousat. Nicméně to že existují veřejné patche znamená, že použitelné řešení existuje ale pochop, že po nich nemůžeš chtít aby přebrali zodpovědnost za kód co neprošel příslušným byrokratickým procesem.

[smazáno]

To nebylo zadne obvineni ale primo reakce na

Možno mám väčší potenciál niekoho ukecať, alebo sa s niekym spriateliť, ale proste tá cesta funguje.

[Bedňa]

Luv, Je divné že práve z teba som mal pocit, že si úplne v pohode a chápeš ako to funguje. Ak sa nemýlim ti prešiel aj zaujímavý patch v Unity.

Skús si, možno to aj robíš neviem, jednať s firmami ako MS, to sa veľmi rád vrátiš k tomu rozbitému Linuxu a slobodnému softvéru.

[smazáno]

Takze jsem se nemylil, fakt si pro FLOSS nehnul ani prstem.

Hlavne ze vis jak vsechno funguje slunickove a z lidi co doopravdy makaj a prispeli do mnoha ruznych OSS projektu delas blce. Kvuli lidem jako si ty jsem do open-source prestal pred lety prispivat.

Kdyz opravis par bugu, co hnijou roky v OSS softu co pouzivaj miliony lidi - a kdyz ten patch protlacis pres maintainera tak to beres jako uspech, casto te proste ignoruje ..., a pak se ti dostane podobnych kecu jak je vsechno slunickovy, a to ze to nedokazes protlacit je tvoje chyba ... tak si pak ty patche nechavas radeji pro sebe zejo ;).

[Bedňa]

Mám dar, že občas to čo napíšem myslím úplne inak ako to druhá strana pochopí.

Dík moc za všetko čo si pre komunitu spravil. Ja vysím denne na IRC, tak na desiatich kanáloch a snažím sa prispievať, ale naozaj na profíkov ako si ty proste nemám.

Proste vychytám sem tam nejaú jednoriadkovú opravu, alebo pomôžem s kompiláciou na Debian like distros, alebo proste len radou. Riešim len to čo používam a netvorím priamo nejaký FLOSS softvér, ale snažím sa pomôcť v rámci svojich možností.

Nič čo som tu napísal som nemyslel nijak ironicky.

Ja vidím ako jedinú cestu ako sa z týchto sračiek vyhrabať jedine spoluprácu. Myslím to všetko okolo mňa. Či už ide o boj patentových trollov, alebo zneužívaní moci atď.

So Long, and Thanks for All the Fish.

[Michal Kubeček]

S vývojármi sa treba snažiť skontaktovať "osobne", proste hodenie problému do "bugzilly" sa nemusí nikto chytiť, pretože ho problém nezaujme.

U jádra to nefunguje téměř nikdy (aspoň v případě bugzilla.kernel.org), to už má větší šanci na úspěch poslat dotaz na příslušný mailing list (a tím nemyslím (jen) LKML).

[pc2005]

Ono to záleží na vývojáři u jednoho to trvalo rok . V bugzille to zase aspoň může hnít jako nevyřešené a někdo si toho může všimnout (občas někdo prochází staré bugy), v lkml se to ztratí do druhého dne.

Zase třeba v GCC bugzille si chyby na 12+ let staré architektuře všiml človek okamžitě a myslím že do +-týdne to opravil.

[snajpa]

Kde jsi vzal, ze bych nekdy argumentoval cenou? Pokud o necem mluvim, je to o Illumosu a ten je open-source, zrovna jako Linux. Ja nerikam, ze se na Linuxu neda nic bezet. Jenom ze ma limity, ktere nejsou moc resene, protoze jsou priority jinde. Treba nejvetsi box v Red Hatu ma presne 1 aktivniho uzivatele a 1 proces se spoustou threadu. To same nejvetsi boxy, o kterych vim, ve vsech moznych firmach. Vetsinou se konci na 128 GB RAM, protoze Linux dal neskaluje.
Ja jsem z toho rozcarovany, protoze jsem to zjistil vicemene az v ostrem provozu, kdy se za boha nemuzeme dostat pres 99.9% a nekdy s nekterymi stroji je uspech udrzet 99.8% dostupnost. Ne ze by to vubec nejelo, ale neda se dosahnout vyssi dostupnost. S KVM/QEMU a nejakym velkym storage polem mimo se dosahnout da, ale zase vykon bude jinde a sdileni prostredku (co se tyce RAM minimalne) bude v podstate nemozne.

[Michal Kubeček]

Kde jsi vzal, ze bych nekdy argumentoval cenou?

Po chvíli hledání se musím omluvit, tuhle konkrétní věc napsal někdo jiný. V tom případě se ale musím zeptat, jak byste v tom případě vysvětlil vy, že i když je Linux (podle vás) od základu navržen úplně špatně a pro enterprise nasazení se vůbec nehodí, stejně ho Google, Facebook, NYSE, LSE, prakticky všechny větší banky, většina větších automobilek a spousty dalších firem přesně pro takové účely používají a dokonce preferují.

Treba nejvetsi box v Red Hatu ma presne 1 aktivniho uzivatele a 1 proces se spoustou threadu.

Nerozumím, proč by tohle měl být argument. Za prvé, naše největší stroje jsou podstatně menší než největší stroje našich zákazníků. Vzhledem k tomu, že mám trochu představu, na čem někteří naši zákazníci SLES provozují, připadá mi téměř vyloučené, že by tomu u RH bylo jinak. Za druhé, pro konkrétní účel může být jeden uživatel a jeden proces se spoustou threadů optimální implementace, takže bez nějaké bližší informace, co ten stroj má dělat a proč je to implementované zrovna takhle, to vaše tvrzení nemá žádnou vypovídací hodnotu.

Vetsinou se konci na 128 GB RAM, protoze Linux dal neskaluje.

Takže když nám přišel bug report, že po upgradu ze 4 TB paměti na 6 TB (asi tak před dvěma lety, dnes jsou IIRC na osmi) jim konkrétní zátěž funguje pomaleji a mají problémy s kdumpem, bylo to celé od základu nesmysl, protože vy přeci víte, že Linux neškáluje už od 128 GB. A SAP asi taky prohlásil SLES za preferovanou platformu pro SAP HANA z čiré neznalosti.

[snajpa]

To je jak mluvit s dubem, ono to zacne zas mlit hovna o nejakejch SAPech. Nevim, jak ti pane vsechna moudrost sveta vysvetlit, co jasne pisu, lip. Kdyz ti rikam, ze linux jako system na uchozeni kontejneru jako time sharing operacni system dneska neobstoji a ty to zas polozis tim, ze davas za priklad systemy, kde se provozuje jedna podelana aplikace, ktera pouziva vsechny dostupny moznosti, aby si ten hw naschedulovala/zmonopolizovala sama, pac se na linux pod sebou spolehnout nemuze... Ale Mistra Kubecka ja presvedcit nepotrebuju. Ja potrebuju, aby nam to fungovalo a na to Kubeckovo kecy, jak je to uzasny, fakt nepomahaji ;)

[Michal Kubeček]

mlit hovna

Úžasný "argument".

Kdyz ti rikam, ze linux jako system na uchozeni kontejneru jako time sharing operacni system dneska neobstoji

Za prvé: s touhle verzí jste přišel až teď. Původně to bylo (přesná citace)

Tim myslim na servery, ne hracky (a ne, Linux tam neni vhodny).

a teď najednou přijdete s tím, že to mělo znamenat jen jeden velmi specifický use case? Za druhé: i pro tyhle účely se Linux dnes běžně využívá - a i v daleko větším měřítku.

davas za priklad systemy, kde se provozuje jedna podelana aplikace, ktera pouziva vsechny dostupny moznosti, aby si ten hw naschedulovala/zmonopolizovala sama, pac se na linux pod sebou spolehnout nemuze

Ani tohle není ani zdaleka pravda, některé z aplikací takhle z praktických důvodů vypadají, ale to je spíš výjimka.

Ale Mistra Kubecka ja presvedcit nepotrebuju.

Ani já necítím potřebu vás o něčem přesvědčit. Jen konfrontuji vaše výkřiky s realitou pro případ, že by je snad někdo chtěl brát vážně.

Je smutné, že jste se odpovědi na jasně položenou otázku vyhnul osobním útokem, ale i tím koneckonců poskytujete hodnotnou informaci.

[snajpa]

Hm. Takze - VFS cachovani (jak kdyby nebylo), scheduling na NUMA + power manager (power management zakazat), tracing - nevim o alternative k DTrace, i kdyz ftrace se k tomu postupne blizi, zas u toho zabreci ten, kdo videl DTrace. Pouzitelny CoW filesystem? Ne, BTRFS mne akorat rozesmejes ;) Fragmentace SLABu (na co mi vcera zrovna umrela masina paradne). User namespace (paradni pruser, v porovnani s puvodni implementaci v OpenVZ, tohle skoro neizoluje). Btw, kde je v kernelu vevnitr nejaky container id? NFS server pod linuxem jsi zkousel pouzivat? Jakoze, vazneji pouzivat? Treba, 1500+ exportu? Vcera se mi to pri rychlem exportu 1500 datasetu zas vysypalo. Ale s nicim konkretnim, zajimavy mezistav, nekoho obslouzime, nekdo ma smulu. Kudyma muzu sahnout do beziciho NFS serveru, abych se mohl podivat presne, co se podelalo, bez toho, abych se musel snazit to zreprodukovat, tj. jak se ted hned podivam, kde se to vymlelo? Videl jsi nekdy system, kde neni inode limit? Videl jsi nekdy system, kde kdyz zvedas pocet otevrenych fd jednomu userovi na stotisicinasobek defaultu, zdaleka nejsi ani prvni, ani desaty, co to tam dela? Videl jsi nekdy, co to dela s kernelem?
Zkus si to u vas v labu rozjet, zkuste si presunout 3-4 tlustsi, poradne zatizene, QEMU hypervisory pod kontejnery. Idealne neco, kde bezi CIcka, databaze, weby, vsechno dohromady to pekne naplacejte, jak je normalni v shared prostredi. Zvladat by to melo, ale to je to, kde se to "melo" zacne prudce rozchazet s realitou.

[snajpa]

Ale jinak, Michale, zvu Vas - tak si tedy tykejme, kdyz na tom trvate - na pivo a tam to muzeme rozebrat zhruba na tom levelu, do kteryho se mi do toho chce stourat, dal - treba srz to, ze bych potreboval nekoho s hands-on zkusenosti, kdo by mohl a mel chut vest nejake skolni prace okolo kernelu, abychom se s tim taky mohli pokusit neco udelat, krome mojeho klasickyho povrchniho picovani na Abicku ;)

[Michal Kubeček]

Není to tak, že bych byl proti tykání, jen mám ve zvyku v diskusích tykat jen těm lidem, které znám osobně a se kterými si tykám i v reálném světě.

Pivu se v principu nebráním, jenom praktická realizace bude trochu komplikovanější tím, že nebydlím v Praze a dojíždím autem (s tím, že v pozdně večerních hodinách by to jinak nešlo ani teoreticky). Ale nepřekonatelný problém to taky není.

[snajpa]

*vykejme, paradni typo :))

[Michal Kubeček]

NFS server pod linuxem jsi zkousel pouzivat? Jakoze, vazneji pouzivat? Treba, 1500+ exportu?

Osobně ne, ale vím, že někteří naši zákazníci ano.

Videl jsi nekdy system, kde kdyz zvedas pocet otevrenych fd jednomu userovi na stotisicinasobek defaultu, zdaleka nejsi ani prvni, ani desaty, co to tam dela? Videl jsi nekdy, co to dela s kernelem?

Opět ne osobně, ale i tady vím o lidech, kteří takové systémy (s Linuxem) provozují. Navíc si vzpomínám na diskusi, kde se člověk s mailem s doménou oracle.com (přesněji řečeno: dva takoví) dožadoval změny chování (aby odpovídalo jeho interpretaci poněkud nejasné formulace v POSIX standardu), ale která by si v důsledku vynutila výrazné snížení výkonu právě v situacích, kdy má tabulka file descriptorů procesu desítky milionů položek.

Netroufám si kvalifikovaně posuzovat implementace scheduleru, memory managementu, VFS, page cache nebo filesystémů, protože to prostě nejsou oblasti, kterými se zabývám (a nevěřím, že existuje člověk, který by tomu všemu rozuměl dost na to, aby to kvalifikovaně posoudit uměl). Dělám core networking, jestli si chcete popovídat o něm, jsem vám k dispozici. Co ale vím s jistotou, je to, že existují velké firmy, které Linux používají právě pro virtualizační servery, pro kontejnery, pro cloud hosting. A při vší úctě k vpsfree, některé i v o dost větším měřítku. Takže si nutně musím položit otázku, jak je možné, že oni nenarážejí na ty neřešitelné problémy prakticky v každém subsystému linuxového jádra, o kterých píšete, a proč oni neupřednostní ty jiné systémy, které jsou pro ten use case ve všech ohledech o tolik lepší.

[snajpa]

Nekde uprednostnili ;) Samsung kvuli tomu koupil cely Joyent, protoze se jim ten jejich SmartOS proste libil a sedi jim to na to, kolik jim to usetrilo racku. Da se to dohledat nekde v tom oznameni, kdyz je kupovali Problem toho ekosystemu je, ze je maly. Ale to neznamena, ze tam nejsou lepsi technologie - minimalne dokud nebudou predehnany necim jinym - a prave mne stve, ze smer je jinudy.

Je tam nahodou spousta veci, co neskalujou, na nekterych vecech se dela, ale nektere veci jsou proste prilis velky sousto - napr. ta defragmentace SLABu by byla potreba jak sul, ale nikdo si nechce vzit na triko to mergovani, i kdyz patchset uz se objevoval v nekolika revizich kdy uz v podstate nesmrdel nikomu.

Neschopnost hnout jakymkoliv smerem s pagecache taky zabiji vykon Linuxu na velkych boxech. Proto si velke aplikace radsi cachuji samy - ale aby to nekdo vyresil primo v Linuxu, to taky nic.

File deskriptory byl asi ten nejdementnejsi a nejvic obvious priklad - kdyz se vezme, ze se nad jednim jadrem udela 100x uplne jinak nastaveny a pouzivany user-space, vznikaji na nej proste tlaky ve smerech, odkud se s tim nepocitalo. Lepsi priklad je vyrabeni interfacu, prace s vecma v ramci net namespace; napr. ladovani iptables pravidel na sdilenym jadru je lahudka.

Bridge dokonce pri masivnim pridavani tapu nekdy ztraci packety..

Memory management je tuneny pro HPC+embedded use-cases, ne pro rich server preplneny cachemi na kazdem kroku. Je rozdil pristupovat k navrhu systemu, kde se budou spravovat absurdni pocty vsech resourcu a je neco uplne jineho, pak dat takove jadro na embedded system s 8 MB RAM. To proste nemuze dlouhodobe vychazet dobre na vsechny strany

I Seznam, Facebook a vsichni, o kterych nejak kousek vim, jak maji infru delanou, tem jadrum nedavaji pocoudit tolik. Na hosta daji 30 kontejneru a ty kontejnery jsou vsechny proste zatizene. A kde to tak neni, tam se to jadro dost tezce tuni, aby se dalo treba turbo rychle spawnovat novy kopie kontejneru, apod.

Muzou mit klidne pul tera ramky per box i vic, ale nepobezi tam typove nic moc, co by se mohlo proti sobe mlatit a nebude tam takovy overcommit, co mame na boxech my.

No, tak se uvidime nekdy na nejblizsi konfere, prinejhorsim, i kdyz bych radeji driv, protoze mne par lidi otravuje, ze by chteli delat kernel-related diplomky (nebo otravuju ja je, ze to chteji delat) ;)

[snajpa]

Jo a velka pointa, co jsem nevypichnul - je obrovskej rozdil, kdyz se o celou infrastrukturu stara nejakym zpusobem konzistentne jedna entita a ma ji celou pod kontrolou. Reseni nad stejnym kernel tech kombem, co jedeme ve vpsFree, kdyz mas pod kontrolou, zasadne obtancujes jinak a hlavne tak, aby se nic neslozilo. Da se to vychytat internim testovanim. Kdyz vis, jakou zatez mas ocekavat, jde to mnohem snadneji ;)

[Michal Kubeček]

File deskriptory byl asi ten nejdementnejsi a nejvic obvious priklad

Když ono je to všechno pořád hrozně mlhavé, bez konkrétních příkladů, co nefunguje dobře, takže je těžké se k tomu nějak vyjádřit. Ale když Eric Dumazet tvrdí, že 10M a víc file descriptorů na jeden listening proces je pro ně běžná záležitost, nemám důvod mu to nevěřit. A jsem si jistý, že kdyby s tím měl výkonový problém, něco by s tím udělal. (Ostatně, už nejméně jednou udělal.)

Lepsi priklad je vyrabeni interfacu, prace s vecma v ramci net namespace

Nějaký příklad? Někde se pořád najdou příklady toho, že se jednotlivé netns navzájem zbytečně blokují, ale obvykle je to spíš proto, že to zatím nikomu nevadilo natolik, aby si stěžoval. Nedávno jsem jeden takový příklad řešil - ale až na základě toho, že se někdo ozval. Při způsobu vývoje linuxového jádra holt nešlo vyhlásit: "Dejte si všichni půl roku pohov, my to zatím celé přepíšeme na netns."

napr. ladovani iptables pravidel na sdilenym jadru je lahudka

Tam jsem na nějaký globální zámek narazil, ale IIRC se to týkalo jen "compat" modu, tj. např. situace, kdy 32-bitový příkaz iptables běží na 64-bitovém jádru. Možná jsou tam i nějaké další, to z hlavy nevím. Ono je celé to rozhraní x_tables, umožňující jen výměnu celé sady pravidel, dost nešťastné, ale to byl koneckonců jeden z hlavních důvodů vzniku nftables.

Bridge dokonce pri masivnim pridavani tapu nekdy ztraci packety.

Tady si nejsem moc jistý, jak to chápat: jestli se během přidávání nového portu ztratí pakety, které by měl bridge forwardovat už existujícím, nebo jestli už to, že má bridge příliš mnoho (kolik?) portů může způsobit, že se začnou ztrácet pakety.

[snajpa]

"Dejte si všichni půl roku pohov, my to zatím celé přepíšeme na netns."

This. To jste vystih a z toho prameni nejvic bolesti. Jinde to prave kvuli nejakemu zasadnimu paradigm shiftu v pouzivani (jako nastup kontejnerizace je) klidne i dyl, nez toho pul roku, predelavaji. Ne, ze by se zastavil vyvoj jinde, ale holt je pak potreba zamergovat neco vetsiho, jak jinak chcete zasadneji preryt treba takovou hnilobu, jako je napriklad okolo pagecache?
Jinak ke konkretnejsim prikladum - klidne se muzeme dohodnout, ze Vam naposilam neco konkretniho, az na to zas narazim, vc. nejakych traces a ceho jsem se dogooglil, ze proc se s tim nebude nic delat, nebo proc je problem s tim pohnout, nebo tak.

[Michal Kubeček]

Ty síťové věci by mne určitě zajímaly.

[smazáno]

jak byste v tom případě vysvětlil vy, že i když je Linux (podle vás) od základu navržen úplně špatně a pro enterprise nasazení se vůbec nehodí, stejně ho Google, Facebook, NYSE, LSE, prakticky všechny větší banky, většina větších automobilek a spousty dalších firem přesně pro takové účely používají a dokonce preferují.

Protoze je levnejsi.

[smazáno]

resp. protoze ja na prvni pohled levnejsi.

Je to podobne jak s javou - taky je z technologickeho (a tudiz i ekonomickeho dlouhodobeho pohledu) absolutne hrozna, ale presto se vsude pouziva, protoze business resi pouze kratkodobe naklady/nezna rozdily mezi technologiemi (zalozime to na linuxu, protoze linux pouziva kazdy -> sezeneme levny lidi ... ale uz nevidi, ze za par let tech lidi bude potreba desetkrat nebo stokrat tolik, nez kdyby se pouzila vhodnejsi technologie). Toto pisu na zaklade zkusenosti jak funguje je z tebou zminenych korporaci.

[smazáno]

obrovsky vliv ma take setrvacnost - pet, deset let zpatky byl linux jedina volba - na skolach/ve firmach se ucil pouze linux, dneska tedy kazdy zna pouze linux a tedy uci pouze linux ..

[Aleš Kapica]

To je vtip, že jo?

[smazáno]

Chapu, ze mas zkusenost, ze vsude byli pouze Windows a Linux byla alternativa - tvoje blogy jsem vzdycky rad cetl.

Ja mel na mysli pouziti o kterem se bavil snajpa a Michal, a ktere prave resim ja poslednich asi tech 10 let, a tam je opravdu celou tu dobu dominantni Linux a nikdo se ani nezamysli ze by to slo jinak.

[snajpa]

Nekde se nekdo evidentne zamejsli, jestli to nejde i jinak ;)

[snajpa]

A nekdo neumi linkovat, takze druhy pokus.

[Aleš Kapica]

Co si tedy já pamatuji, tak mnohem rozšířenější v té době byl Novell a Sun. A to jak dopadly je podle mě důsledek jejich licenční politiky. Linux nebyl upřednostněn protože by byl levnější, ale protože má mnohem transparentnější vývojový cyklus a širší uživatelskou základnu. A co je také podle mne nezanedbatelný faktor – díky GPL licenci jsou uživatelé nuceni poskytovat kód v otevřené podobě dále. Ať si má někdo Stallmana za magora, tak za to, že je dnes k dispozici otevřená alternativa, vděčíme právě jemu. Já si ještě moc dobře pamatuji dobu, kdy nebyl k dispozici žádný opensource. Ostatně, s Linusem jsme vrstevníci.

[hypvofxy]

Je to presne naopak. Java je nevhodna na rapid prototyping a vyhody naopak muze prinaset v dlouhodobem behu. Podobne tak se s masovym rozsirenim JavaScriptu objevilo uzivani lintu a snahy zavest silne typovani.

[smazáno]

tu poznamku o jave jsem si mohl odpustit - rikal jsem si ze to zbytecne vyprovokuje diehard javisty

pobavilo me jak predpokladas, ze muj problem s javou je strong typing - vubec ne, striktni dynamicke typovani osobne povazuji za stejne spatne jako strong typing - optional typing ftw :) - problem s javou je celkove zaseknuti v osumdesatkach (dobre, mozna zacatku devadesatek).

Je to krasny priklad one setrvacnosti, dokonce vylozene extremni. Takto nas to ucili, takto to budeme delat, a budeme to ucit dal, jinak to nejde.

[hypvofxy]

rikal jsem si ze to zbytecne vyprovokuje diehard javisty

Tak bych se neoznacil. Netajim se tim, ze mam Javu rad, ale muj pristup k ni je ryze pragmaticky. Tj. o ruznych bolestech Javy bych mohl sepsat poradne tlustou knihu, ale presto lepsi alternativy moc neznam. To neznamena, ze Java ma tak blizko k idealu, jako to spis vypovida neco nepekneho o vyvoji ostatnich jazyku, kdy lze casto videt znovuvynalezani kola, ale uz ne tak casto skutecny vyvoj ve vedeckem, nebo alespon pseudovedeckem, vyznamu.

pobavilo me jak predpokladas, ze muj problem s javou je strong typing

Pravda. To jsem tak nejak vychazel z jednoho z nejcastejsich argumentu.

optional typing ftw :)

Souhlasim. Proto jsem se zacal zajimat o jazyk Groovy.

problem s javou je celkove zaseknuti v osumdesatkach (dobre, mozna zacatku devadesatek).

To by bylo potreba dal rozvest. Osobne spis problemy v Jave vidim jinde. Namatkove bych zminil type erasure u generik, primitivni typy a autoboxing a prinejmensim sporne jsou rovnez checked vyjimky (ve stavajici podobe). C# je v techto 3 bodech dal a vice ci mene uspesne je resi, ale bohuzel (k moji znalosti) zatim neni tak vyspely ekosystem okolo nej, tj. zejmena podpora jinych platform nez MS Windows, konkurence na poli IDE apod.

Je to krasny priklad one setrvacnosti, dokonce vylozene extremni. Takto nas to ucili, takto to budeme delat, a budeme to ucit dal, jinak to nejde.

Ona je totiz otazka, jak (co) delat jinak. Neni nutne neustale prichazet s novymi trendy a bourat stavajici principy, ackoliv to nic noveho neprinasi.

Vyvoj obecne znamena, ze zachovam to, co se osvedcilo, a pokusim se napravit to, co se naopak neosvedcilo. To bohuzel vidim malo casto. Treba Python prinasi mnoho dobreho (yield, array slicing), ale pro zmenu v nem zcela chybi staticke typovani. Existuje sice PEP 484, ale ten se vztahuje jen na argumenty a navratove typy funkci a runtime validace lze delat jedine pomoci externi knihovny, ktera vyzaduje, aby byl kod dale anotovany.

Pak jsou tu jazyky jako Scala (se kterou jsem se zatim jen velmi zbezne seznamil), ale jsou pro zmenu natolik slozite, ze kazdy tym bude muset sepisovat, udrzovat a dodrzovat striktni guidelines, jinak by v trochu vetsi code-base driv nebo pozdeji byl totalni gulas, kde by kazdy programator pouzival naprosto odlisny pristup k reseni problemu.

[smazáno]

optional typing v groovy je zatim nejlepsi co jsem videl; o zbytku jazyka uz to bohuzel rict nemuzu - vetsina problemu je ale primo nasledek toho jak vychazi z javy

[Bedňa]

Protoze je levnejsi.

Asi žiješ v nejak inom "Enterprise", cena je posledné čo sa rieši. Teda áno ona sa rieši v excelovskej tabuľke s parametrami vycucanými z prsta a zrovna ten MS to robí aj tak najlepšie, pretože sa vie z manažérmi vždy podeliť.

Vo finále to je vždy drahšie. Nehovorím o ničom čo by som nezažil. Rozmýšľal som aj nad blogom, ale ako sa pozerám okolo, bola by to úplne zbytočne vynaložená energia a to už proste nerobím.

[smazáno]

Mam zkusenosti ze segmentu, kde je MS irelevantni jeste vice nez BSD.

[trekker.dk]

Ja jsem z toho rozcarovany, protoze jsem to zjistil vicemene az v ostrem provozu, kdy se za boha nemuzeme dostat pres 99.9% a nekdy s nekterymi stroji je uspech udrzet 99.8% dostupnost.

Jestli ono to náhodou nemá souvislost s použitými technologiemi. Vezmeme Linux, dopatchneme do něj out-of-tree filesystém, do toho dopatchneme out-of-tree popelnicovou, pardon, kontejnerovou virtualizaci a voila, ono to nefunguje. Stěžujete si tady na Linux, ale argumentujete problémem, který se vyskytuje ve vaší upravené verzi.

S KVM/QEMU a nejakym velkym storage polem mimo se dosahnout da, ale zase vykon bude jinde

Jenom pro srovnání jsem si teď vytáhl z Nagiosu několik strojů - všechno 2 socket Xeon, 256GB RAM, z toho využito 100-150GB se zapnutým KSM, běží na tom Qemu z lokálních disků. Používá se lehce překonfigurované distribuční jádro z Jessie a dostupnost těch strojů za poslední rok je ve většině případů více než 99.99%. A jsou to plánované noční odstávky, ne výpadky přes den.

Výkon? Stroj, který spadl přes den, žádný výkon nemá.

sdileni prostredku (co se tyce RAM minimalne) bude v podstate nemozne.

25% redukce využité paměti je málo?

[snajpa]

Protoze technologie v upstream kernelu se pouzit neda - kontejnery maji slabou izolaci a celkove dost dementni navrh, na ktery se odmitam spolejhat + v Linuxu chybi poradny storage subsystem.

25% redukce využité paměti je málo?

Jo, dost malo. Vem si, ze my v tech 256GB mame 100 kontejneru, kazdy ma nastaveny 4 GB RAM strop, v ZFS ARC je okolo 60-100G a zbytek drzi kontejnery, kde nejaka mean hodnota toho, co zabira jeden kontejner v pameti, vychazi na 1 GB. Tim, ze se starame o cachovani cele node najednou, si takovyhle overcommit muzeme v pohode dovolit a nikdy nenarazime na OOM - maximalne na situaci, kdy ZFS musi odcouvat a uvolnit kus pameti. A v takovych situacich ma zrovna prave Linux problem.

[Aleš Kapica]

No vidíš. Máš k dispozici systém, který splňuje tvoje požadavky, jinému splňuje linux jeho potřeby již ve stavu, v jakém zrovna je. Tak na co si stěžuješ? Chtít jeden univerzální systém je přeci naprostá konina.

[trekker.dk]

Protoze technologie v upstream kernelu se pouzit neda - kontejnery maji slabou izolaci a celkove dost dementni navrh, na ktery se odmitam spolejhat + v Linuxu chybi poradny storage subsystem

Jo, souhlas, taky je nepoužívám. Ale pokud chci lepší kontejnery a lepší storage a do Linuxu si to dopatchuju z out-of-tree zdrojů, není chyba Linuxu, když to potom není stabilní. A rozhodně je nesmysl z toho a z chybějící podpory kontejnerů odvozovat, že Linux je systém pro hračky. Zejména s ohledem na reálná nasazení.

Tim, ze se starame o cachovani cele node najednou, si takovyhle overcommit muzeme v pohode dovolit a nikdy nenarazime na OOM

Takže když si všech těch 100 kontejnerů nastaví innodb_buffer_pool_size v MySQL na 3GB, tak to ta mašina utáhne? Dost o tom pochybuju. Neříkám, že cache přes celý node je k ničemu, ale v nadšení tomu přisuzujete až moc zázračné vlastnosti.

maximalne na situaci, kdy ZFS musi odcouvat a uvolnit kus pameti. A v takovych situacich ma zrovna prave Linux problem.

Linux nebo Linux+ZoL? Protože s Linuxem se mi ještě nestalo, že by uvolňování cache způsobilo pád jádra.

[snajpa]

není chyba Linuxu, když to potom není stabilní.

To teda je, a krom toho v posledni dobe to neni jenom ZFS, ale je tu taky BTRFS a Ceph, oba dva zatezujou pametovej subsystem vic, nez se pocitalo. A do uzkych se muzes dostat i na mensich systemech s ext4, ani se clovek nemusi moc snazit. Resi se to v tech diskuzich na LKML znova a znova a nikdo nema koule prijit s nejakym radikalnejsim resenim, natoz ho zamergovat.

Linux je systém pro hračky. Zejména s ohledem na reálná nasazení.

Ja mam rad dramatickou nadsazku, jestli jste si tu este nevsimli

Linux je systém pro hračky. Zejména s ohledem na reálná nasazení.

No, kontejnery bezime uz od zacatku roku 2009 a kdyz uz se obtezuju s prezentovanim nejakych konkretnejsich cisel a ne jenom trolovanim (napr. ten 1 GB viz. vys), tak si je necucam z prstu. Kdyby ten pomer byl jinde, nez jak je, zaridili bychom se podle toho. Jenze naprosta vetsina lidi ma tu MySQL smutne v defaultu. Tady musim priznat, ze jdeme kousek proti sobe tim, ze nechavame ZFS cachovat, co se da - protoze spousta lidi si ani nikdy nevsimne, ze by MySQL meli nejak nastavit jinak, ze ten default je dost bida na maly systemecky... Pak se az divi, kdyz to presouvaji jinam/na svuj HW, co ze to najednou dre o disky

by uvolňování cache způsobilo pád jádra.

Pad jadra ne, to se opravdu nedeje. Ale ze se system zasekne v nekonecnym cyklu memory reclaimu, to se teda deje - a jak pisu, nemusis mit zrovna ZoL, ale tam je to nejvic evidentni.

[trekker.dk]

No, kontejnery bezime uz od zacatku roku 2009 a kdyz uz se obtezuju s prezentovanim nejakych konkretnejsich cisel a ne jenom trolovanim (napr. ten 1 GB viz. vys), tak si je necucam z prstu.

To samozřejmě netvrdím. A jo, je mi jasné, že kdyby to využití paměti vypadalo jinak, tak se podle toho jinak nadimenzují nebo zatíží servery. To důležité, co jsem chtěl ukázat, je, že ten overcommit si můžete dovolit díky reálným poměrům na tom serveru a ne díky cache přes celý stroj.

Pad jadra ne, to se opravdu nedeje. Ale ze se system zasekne v nekonecnym cyklu memory reclaimu, to se teda deje

Jo, jasně, to jsem měl na mysli - a jak říkám, s "vanilla" (Debian) jádrem se s tím nepotkávám.

[Vykook]

Víš jak se říká tomu co jsi napsal? Dojmologie. A víš jaká je argumentační hodnota dojmologie? Nulová. Mimochodem, nic jako nedobrovolné přispívání do BSD neexistuje. Teda za předpokladu že ti Dillon neunesl dítě a nepustí ho až po tom co uděláš push do repozitáře.

P.S.: Fakt netuším co to má společného s rozbíháním disribucí ve virtualizaci, ale to už je asi jedno...

[Aleš Kapica]

Instalace do virtuálu má nulovou vypovídací hodnotu. Pokud se teda neměl blogpost správně jmenovat "Instalátory linuxových distribucí 2017 - pár postřehů"

[trevor12]

tak bohuzel ve svete OSS ani instalace do virtualu nemusi byt nic trivialniho a dokaze byt pekne nepratelska- viz me pokusy s openbsd, netbsd, freebsd, slackware a dalsi neuspesne pokusy s ruznymi linux distribucemi popsane v clanku ... na fyzicke zelezo by to bylo o nekolik radu slozitejsi aby vsechen hw fungoval .. bohuzel takovy je stav v roce 2017, jedina distribuce kde mi vsechno (vsechen fyzicky hw) jelo out of the box hned po bootu (instalaci) byl knoppix ktery se ale bohuzel neinstaluje (tu moznost ulozit si na usb flash disk zmeny neberu, to neni plnohodnotne desktop distro)

nechapu proc si distribuce hrajou na nejake free non-free, vsechno ma byt rovnou funkcni na prvni tuknuti pri instalaci, knoppix to jedinej ma vyreseny ...

[Franta]

Proč? Protože ty ovladače distribuce nemůžou ovlivnit. Pokud dáš do distra binární bordel od kdovíjakého vendora, tak nikdy nevíš, co se může mezi tím ovladačem a zbytkem distribuce rozbít a uživatelé/zákazníci od tebe očekávají, že to bude fungovat, když to distribuuješ, a když něco nefunguje, tak že to rychle opravíš. Jak je to binární ovladač, tak s tím sám nic neuděláš a vendor na tebe může úplně kašlat. Nějaké hobby distribuce jako Knoppix si to můžou dovolit, ale ty seriózní pro seriózní nasazení už si to třikrát rozmyslí.

Jak je svět binárních ovladačů boží, lze dokonale vidět na mobilních chipsetech. Výrobce poskytne nějaký binární ovladač, po roce a půl zařízne podporu, na novějších kernelech už nefunguje a výrobci telefonů a jejich uživatelé mají smůlu a můžou ty zařízení zahodit, pokud se nesmíří s tím, že je to ztělesněný bezpečnostní cedník. Mnohem raději budu, když se budou distribuce k binárním ovladačům stavět zadkem a budou tak tlačit na to, aby byly k dispozici ovladače otevřené. Že kvůli tomu strávím 5 minut navíc, abych doinstaloval ovladač od Nvidie nebo od Broadcomu, rád přetrpím.

[trevor12]

v knoppixu nic nepada tak nevim ... navic rozchazovani hw napr. wifi dle vlastnich zkusenosti rozhodne neni vec na 5 minut .. kdyz uz podpora neni primo v kernelu tak by to melo byt kompilovane se vsemi moznymi moduly a pak by treba stacilo modprobe ...

[hypvofxy]

V ~15 letech jsem nainstaloval a uspesne pouzival Fedoru 6 na fyzickem stroji. Kdo jsi ty a s cim presne mas problem netusim, ale zapisek, kde vety nezacinaji velkym pismenem, nekonci teckou a chybi mu formatovani, neni hodny cteni a vypovida neco nepekneho o jeho autorovi. Pokud mas nejake konkretni dotazy, smeruj je do poradny. Jestlize bylo naopak cilem toliko se podelit o vyroky fungovalo vs. nefungovalo bez nejakeho dalsiho zduvodneni, tak prosim, ale necekej nejakou konstruktivni diskuzi.

[trevor12]

jde o obsah ne o formu, sere pes na grammar nazis ... pokud to nehodlas cist tak to necti ...

[hypvofxy]

Existuji prumyslove standardy, a stejne tak existuje gramatika a stylistika, aby se ten obsah dal precist pri vynalozeni co nejmensiho usili. Ja vetsinou pisu bez diakritiky a dalsich ceskych znaku (pomlcek, spojovniku, ceskych uvozovek), coz muze udelat rozdil, rekneme, 5 - 10 % v citelnosti pro vetsinu lidi (kde citelnost je parametr, ktery zahrnuje cas straveny ctenim, presnost prenosu informace, resp. mnozstvi sumu, a pripadne subjektivni pozitek ze cteni). Protoze tak ale pisu o dost rychleji, povazuji to za akceptovatelne (a samozrejme plati, ze pokud to nekomu vadi, cist to nemusi; az to zacne vadit nadmernemu mnozstvi lidi, budu muset svuj navyk v tomto smeru upravit).

Ty oproti tomu nepouzivas ani ve clanku radne strukturovani do vet a zakladni stylistiku a formatovani, coz pro me osobne citelnost snizuje uz velmi vyrazne, a ocividne nejsem sam, protoze uz to v teto diskuzi bylo vytknuto i nekym jinym.

Ze stejneho duvodu existuje logopedie, protoze na kvalite projevu (v tomto pripade nikoliv psaneho, ale mluveneho) proste zalezi; ovlivnuje to usili, ktere ostatni musi vynalozit na to, aby informaci dekodovali.

A co se tyka poznamky, ze jde o obsah, tak bych podotkl, ze moje vytky v predchozim komentari (a opet to zaznelo i z jinych mist v diskuzi) smerovaly i k obsahu.

A nebo mi snad majitel Macbooku bude tvrdit, ze kdyz mu poskodim reproduktor a snizim rozliseni displeje na tretinu, tak sledovani zaznamu prednasky bude naprosto stejne pohodlne, protoze prece obsah je stejny a zmenila se jen forma?

[Franta]

V Knoppixu nic nepadá teď a tobě. To je pro distribuce, které mají miliony instalací a často v kritických nasazeních, dost málo. Nevím, jakou wifi myslíš, ale ovladače v mainline kernelu nemá snad jenom Broadcom. Jejich instalace znamená: připojení přes ethernet nebo přes USB tethering z telefonu, vygooglení návodu, přidání repozitáře, instalace jednoho balíčku, restart. Pro zkušeného uživatele Linuxu práce na 5 minut, pro nezkušeného pravda třeba na půl hodiny, ale zase to je věc, kterou dělá jednou za čas.

[trevor12]

kdyz to Knoppix umi tak proc to jine distribuce take neumi ? mne by to potesilo kdyby mne zbavily teto starosti a chodilo to .. nevim jestli kdyz to neni primo v kernelu by to nemohlo byt jako modul nebo nejak jinak pripojit aby uz pri instalaci wifi broadcom chodila ...

[Vykook]

Já tím nereaguju na samotný zápisek, kterej je až na přehlednost podle mého v pohodě, ale naopak na debatu o sw licencích a podobnejch chujovinách, která se tu rozjela následně.

[Aleš Kapica]

No právě. Zcela zbytečná OT diskuze.

[Bedňa]

Jasne chýbajú nám hipstery a ďalšie zbytočné cool vecí. Nedá sa softvér šíriť len ako blob a nič nevracať komunite. Krása, už aby si sa tam zas vrátil.

[Vykook]

Z toho že se něco vracet nemusí, nutně neplyne, že nikdo nic nevrací. To jsi fakt takovej argumentační mrzák, že musíš dělat osobní výpady?

[Bedňa]

Jasne že sa vracia, kto stavia svoje riešenie na nejakom slobodnom modele (hoci tu by som upozornil na rozdieľ medzi slodou a anarchiou) keď vyrastie do väčšej firmy si bude nechávať písať základ pre biznis, pretože je to lacnejšie.

Ďalší problém je s tým, že pri BSD si pritom kutí svoje vyvhytávky a k tým sa už nikto nedostane a každý ďalší bude musieť to koleso vymýšľať odznovu.

Zemeguľa je ale len jedna a míňanie energie na to isté dookola, nás stojí veľa energie a spomaľuje vývoj.

BSD samozrejme nijak nerieši ani patenty čo je ozajstný zabiják inovácie. Tu môže nastať otázka ako odmeniť človeka čo niečo unikátne vyvinie, ale aj to by sa dalo nejak vyriešiť. Dnes tu ale existuje patentové mínové pole aj vďaka ľuďom ktorí si myslia, že vymsleli oblé rohy, vesmír, je to zlo.

[tonda]

Manjaro – dokazal jsem nainstalovat, smutek ze neni AUR jen vlastni repo manjara kde je toho oproti AURu hodne malo, pry AUR se da manulane zapnout jak a kde ?

$ yaourt -Ss balíček #najde balíček v AURu

$ yaourt -S balíček # nainstaluje balík z AURu

Případně:

nainstaluj #pacman -S --needed base-devel

stáhni si balíček (tarbal) na webu AUR archlinuxu

rozbal balíček $ tar xvzf balicek.tar.gz

presuň se do adresáře kde je balíček

$makepkg -s (jako root to nejde)

Po provedení #pacman -U /cesta/pkg.tar.xz (balíček tar.xz byl vytvořen příkazem $makepkg)

A soubor je nainstalovaný.

Pro odstranění #pacman -R nazev_baliku

[trevor12]

tak upgrade clanku na 2019

jedu na fyzickym zeleze Manjaro (nema chybu !) a Kubuntu ale nekdy se v myslenkach stale vracim k "cistote" Debianu co jsem pouzival jako prvni