Příspěvky

3901

Desktop / Re: *BSD na desktopu

« kdy: 17. 08. 2015, 16:44:40 »

FreeBSD vyuzivaju firmy ako NetApp, Juniper Networks, Cisco, Google, <dopln velku korporaciu> (cit tam licenciu).

Nezapomeň na PlayStation 4!

to Prýmek: Máš na mysli asi Grub2 že? Protože mě 1 (respektive 0.9 nebo tak nějak) přišla skvělá a čitelná. Bohužel 2 zmršili dost nehorázným způsobem (ano funkčně je to někde jinde - srovnání třeba jako fabia vs lamborgini, ale když vemu v potaz, že je to jen loader, tak tenhle trend moc nechápu).

Jo. Jsem si vědom toho, že funkčně je to jinde, ale já moc nechápu přinos té funkčnosti. Není lepší mít jednoduchý loader, který umí jenom jeden FS? Prostě si /boot dám na onen FS a zbytek už úplně na co chci - a podpora těch různých FS se mi nesmyslně neduplikuje v loaderu a kernelu... Je to krásný, čistý, přehledný. Pohodička.

3902

Hardware / Re:Co se děje při přejmenování souboru?

« kdy: 17. 08. 2015, 08:49:00 »

Takže proč tomu dávat laicky nepřívětivé názvy.

Protože ten pojem pochází z dob, kdy žádní laici s počítačem nepracovali, takže nebylo potřeba vymýšlet intuitivní metafory.

Nejspíš to bude pocházet z dob, kdy žádné soubory nebyly, byla jenom data uložená na nějakém mediu od indexu i1 do indexu i2 (-> dataset). Aby nevznikaly chyby, vymyslel se adresář (katalog), který datasetům přiděloval jména.

Hezky je to popsáno tady: http://bitsavers.trailing-edge.com/pdf/ibm/360/os/R01-08/C28-6535-0_OS360_Concepts_and_Facilities_1965.pdf strana 10

3903

Desktop / Re:*BSD na desktopu

« kdy: 17. 08. 2015, 01:26:03 »

Jde FreeBSD nějak rozumně nainstalovat na existující ZFS pool? Handbook o tomhle mlčí, existuje sice wiki page Root on ZFS, ale je to označený jako outdated a jedna sekce dokonce "does not boot" (lél). Instalátor umí použít jenom nově vytvořenej.

FreeBSD je narozdíl od Linuxu monolit, takže instalace samotného OS spočívá v tom, že někam rozbalíš dva archivy - např. odsud http://ftp.cz.freebsd.org/pub/FreeBSD/releases/amd64/amd64/10.2-RELEASE/ si stáhneš base.txz a kernel.txz.

Pak potřebuješ ještě zajistit, aby ti ten systém bootoval, přesný postup záleží na okolnostech (hlavně jestli je to multiboot nebo ne). Pokud je to disk jenom s FreeBSD, tak celý postup je tady: https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/9.0-RELEASE - body 4 a 5. Jde prostě o to, že máš GPT partition table, na místo, kde je normálně MBR nahraješ /boot/pmbr, první partitionu vytvoříš s typem freebsd-boot a nahraješ tam loader /boot/gptzfsboot a na druhou partitionu dáš zpool. Pak už jenom označíš, ze kterého ZFS svazku se má bootovat a je hotovo. Žádný zvěrstva s ramdiskem, jenom dva soubory s loaderem a zfs pool

3904

Windows a jiné systémy / Re:WS 2008 Std. SNMP RAM

« kdy: 10. 08. 2015, 15:48:38 »

Uprimne netusim jak z toho vypocitam vyuziti pameti. Server ma 16Gb RAM a 6,8 aktualne pouziva

Tohle třeba bude včetně cache nebo tak něco, protože by to mělo být takhle:

Kód: [Vybrat]

>>> (147819*65536)/1000000
9687

Možná mají Windows ještě nějaké jiné OID s přesnějšími informacemi. To už nevím.

3905

Windows a jiné systémy / Re:WS 2008 Std. SNMP RAM

« kdy: 10. 08. 2015, 15:28:38 »

Takhle?

Kód: [Vybrat]

HOST-RESOURCES-MIB::hrStorageType.4 = OID: HOST-RESOURCES-TYPES::hrStorageVirtualMemory
HOST-RESOURCES-MIB::hrStorageType.5 = OID: HOST-RESOURCES-TYPES::hrStorageRam
HOST-RESOURCES-MIB::hrStorageDescr.4 = STRING: Virtual Memory
HOST-RESOURCES-MIB::hrStorageDescr.5 = STRING: Physical Memory
HOST-RESOURCES-MIB::hrStorageAllocationUnits.4 = INTEGER: 65536 Bytes
HOST-RESOURCES-MIB::hrStorageAllocationUnits.5 = INTEGER: 65536 Bytes
HOST-RESOURCES-MIB::hrStorageSize.4 = INTEGER: XXXXX
HOST-RESOURCES-MIB::hrStorageSize.5 = INTEGER: XXXXX
HOST-RESOURCES-MIB::hrStorageUsed.4 = INTEGER: XXXXX
HOST-RESOURCES-MIB::hrStorageUsed.5 = INTEGER: XXXXX

3906

Vývoj / Re:Je C++ dobrá volba na větší projekt?

« kdy: 04. 08. 2015, 09:18:23 »

No právě. A to je v 21. století poněkud trapné, že se v jazyce nedá rozumně psát konkurentní aplikace...

Tohle musím upřesnit: ne v jazyce, ale v jeho konkrétní implementaci. IronPython ani JPython afaik GIL nemají.

3907

Vývoj / Re:Je C++ dobrá volba na větší projekt?

« kdy: 04. 08. 2015, 08:43:13 »

Souhlasím, že v GUI aplikacích to využiju parádně, moje vyjádřená pochybnost (Python jako lepidlo) se však týkala jen grafické vrstvy GUI aplikace. Proto nekliknu a nepřepočítává... po kliknutí se spustí nativní aplikace, jejíž procesorový čas řídí OS a ne Python. Zatímco já si povídám skrz guiksicht s Pythonem, nativní aplikace vyřeší multiprocesorově problém a výsledek přichystá Pythonu na podnose, kde si ho příležitostně vyzvedne a použije v komunikaci se mnou.

Spouštět pro každou GUI událost (to nemusí být jenom kliknutí, ale třeba i najetí myší do nějaké oblasti) by bylo tragicky neefektivní a nedělá se to tak. Když už se chce tahle masařka Pythonu obejít, dělá se to tak, že se GIL releasne (to má nějaké předpoklady) a provede se nativní kód v novém vláknu. Nebo se v novém vláknu spustí celý nový interpret. Každopádně to znamená, že v tom novém vláknu nemůžeš volně manipulovat s datovými strukturami, se kterými jinak v Pythonu pracuješ.

Pokud by se to dělalo tak, jak píšeš, tak by tam ten Python byl jenom na ozdobu, protože drtivá většina zpracování by jela v tom jiném jazyce.

Proc by to bylo trapne? Realita je, ze nikdo nevi co s tim.

No právě. A to je v 21. století poněkud trapné, že se v jazyce nedá rozumně psát konkurentní aplikace...

A pokud vim, tak GIL je problem pouze u CPU-bound aplikaci, ktere jsou napsane primo v Pythonu. GIL neznamena, ze Python nemuze provadet veci konkurentne (jako treba GUI vlakna), ani to neznamena, ze ho externi knihovna nemuze obejit.

Jasně. Ale je to prostě opruz, musí se to řešit, vznikají chyby, kód je složitější... Je to prostě podobná berlička jako když do by-design jednovláknového JavaScriptu namatleš tisíce callbacků (ideálně vnořených tak do 5. až 75. úrovně) a pak ti z toho jde hlava kolem...

Konecne, kdyby se GIL odstranil, znamenalo by to snizit vykon jednoduchych (jednovlaknovych) skriptu, coz je asi tak 90% vyuziti Pythonu.

Nemám proti Pythonu vůbec nic, je to podle mě nadstandardně pěkný jazyk a na skripty ho používám moc rád, ale na větší věci (a to je naše téma) se podle mě moc nehodí, hlavně kvůli GILu a ani volitelné podpoře typů. Že je dneska móda cpát Python všude a ohýbat ho na všechno, je jiná věc.

Navic, diverzita je dulezita; kdyby vsechno fungovalo (/bylo navrzene) jako JVM, jaky by to melo smysl?

Na tom něco je. Potom ale jestli je semafor dobře navržený na to, aby řídil dopravu, nemusí být úplně dobrý nápad ho používat jako soustruh. Od toho tu je prostě soustruh, který se na to hodí líp

3908

Vývoj / Re:Je C++ dobrá volba na větší projekt?

« kdy: 03. 08. 2015, 14:54:26 »

Trapný to je, ale když to člověk vezme pragmaticky -
- python jako glue (formuláříky, okýnka, odstartovávání nativních rutin...) - k tomu přeci není třeba usilovat o využití všech jader na plný plyn

Prave naopak - v GUI aplikacich dobry multithreading vyuzijes paradne, protoze kdyz na neco kliknes a ono se tam neco prepocitava, tak nechces, aby ti GUI zamrzlo. U by-design unithreadovych jazyku to pak musis ruzne obchazet, coz je zbytecna namaha. Z hlediska programatora to muze byt neviditelne schovany nekde v hloubce nejakych knihoven, ale opruz to je a dusledky to ma i tak, i kdyby jenom v tom, ze je vyvoj knihoven pomalejsi a nekompatibilni zmeny API castejsi.

- na spuštěnou C++ nativní rutinu si už žádný GIL nepřijde

Pokud se GIL spravne releasuje, tak ne, ale zase: musi se na to myslet, je to uplne zbytecnej opruz.

Treba ted je desne cool pouzivat Python pro zpracovani dat (pandas atd.) a kazdou chvilku nekdo prijde s tim, ze nejakou CAST nejakeho vypoctu udelal s releasnutym GILem a vypocet se zrychlil o stovky procent. No to je parada, ale dela se to ad hoc, misto aby se to nemuselo resit vubec, nebo aspon nejak inteligentnejc.

... takže ve výsledku  můžu mít aplikaci, kdy do pythonovskýho formuláříku klepu vstupní data a na pozadí mi X céčkových subrutin roztáčí větrák na plný plyn, nebo mi něco uniká?

Ano, pokud na to myslis, patricne knihovny to podporuji a jsou prelozene s patricnymi optionami, udelal jsi kolem serveru kridou pentagram a obetoval panenskeho holuba

3909

Sítě / Re:Firemní politika při správě sítě

« kdy: 03. 08. 2015, 13:14:47 »

v praci ted frci LEAN. vicemene to je snaha o robotizaci vyvojaru ....

Jasne, frci NoOps, akorat s jeho zavadenim a udrzenim nevyzkousenych veci v chodu je tolik prace, ze je na to potreba mozna jeste vic ops nez predtim

3910

Vývoj / Re:Je C++ dobrá volba na větší projekt?

« kdy: 03. 08. 2015, 12:04:56 »

A proč neudělat kritický části v C/C++ a celý to pak slepit třeba Pythonem? V čem by bylo tohle řešení obecně méně výhodné, než Java?

V tom, ze Python ma GIL a zjevne se s tim nic moc delat nebude. Coz je v 21. stoleti ponekud trapne

3911

Sítě / Re:Firemní politika při správě sítě

« kdy: 03. 08. 2015, 10:33:21 »

Jedna věc, která funguje spolehlivě, je firmu pravidelně obcházet a ptát se lidí, jestli je všechno v pořádku a jestli nepotřebují s něčím pomoct. Tímhle způsobem ale dost pravděpodobně spadneš do druhýho extrému: lidi po tobě budou chtít, abys jim pomohl udělat tabulku v excellu, řešil nepodstatné chyby Windows a aplikací apod. Samozřejmě to asi není použitelný všude, ale ve většině firem asi jo.

Taky není od věci získat nějaký kanál, kterým se ti dostanou zákulisní informace. Je klidně možný, že důležitosti tvé práce jsou si rozhodující lidi vědomi, nic ti nehrozí a je to jenom tvoje paranoia

3912

Vývoj / Re:Je C++ dobrá volba na větší projekt?

« kdy: 03. 08. 2015, 10:19:20 »

Ve kterém případě není životnost zdroje vázána na některý scope?

Nejde o to, jestli na některý, ale jestli na nějaký konkrétní.

3913

Desktop / Re:*BSD na desktopu

« kdy: 02. 08. 2015, 18:42:33 »

Nechceš radši použít btrfs?

Btrfs nenamountuje na FreeBSD, kdyžto ZFS na Linuxu namountuje.

3914

Desktop / Re:*BSD na desktopu

« kdy: 02. 08. 2015, 02:19:58 »

Výborně to celý vystihuje tenhle post: https://forums.freebsd.org/threads/current-vs-stable-vs-release.3716/#post-90077

3915

Desktop / Re:*BSD na desktopu

« kdy: 02. 08. 2015, 02:14:10 »

Ještě k samotnýmu FreeBSD, jak dobře (ne)funguje CURRENT? Je to přirovnatelný k linuxovým rolling release distrům (Arch, Gentoo testing), nebo je na tom se stabilitou hůř?

Především si musíš uvědomit, že FreeBSD je jenom základní OS (tzv. "base"). Toho se týká tohle verzování. Všechno ostatní je v portech, které jsou (až na drobounké detaily) společné pro všechny verze a jsou dost bleeding edge (kromě věcí, u kterých nová verze vyžaduje nějaký netriviální portovací úsilí).

Base je opravdu základ, oproti linuxovým distrům bys mohl být dost překvapený, co tam je/není - nejsou tam ani Xka, ani bash (základní shell je tcsh) ani mc Co všechno tam je, se můžeš podívat sám: http://ftp.cz.freebsd.org/pub/FreeBSD/releases/amd64/10.1-RELEASE/base.txz (63MB)

Takže jet na -CURRENT je dobré jenom v případě, že chceš podrobněji sledovat vývoj, potřebuješ nějakou nedávno přidanou podporu hw apod. a zároveň jsi ochotný jít do poměrně velkého rizika. Rozhodně to nemá cenu proto, abys získal novější apache - budeš ho mít totiž v úplně stejné verzi jako na -RELEASE

Když už bys z nějakého důvodu chtěl častější updaty, tak na normální použití je rozhodně rozumnější -STABLE než -CURRENT. Ten by měl být poměrně rozumně použitelný.

Jinak viz https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html