Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Vladimír Drgoňa

Stran: 1 ... 9 10 [11] 12 13 ... 41
151
Hardware / Re:Radeon R7 360 na Debianu
« kdy: 06. 12. 2016, 11:23:59 »
Ahoj, presne takúto kartu mám v mojom PC, mám tam Gentoo a ide mi bez problémov sopensource ovládačmi xf86-video-ati aj xf86-video-amdgpu, potreboval som akurát linux-firmware, prípadne amdgpu-ucode. Driver Amdgpu-pro priamo od AMD som neskúšal - nebolo treba, výkon mi dostačuje a nemám žiaden problém so stabilitou.
Predpokladám, že v Debiane karta pôjde okamžite, prípadne po stiahnutí linux-firmware.

152
Distribuce / Re:Mint a mrznutie javy, alebo náhrada Esplorera
« kdy: 04. 12. 2016, 21:35:59 »
Akú používaš javu? Je to oracleJDK/openJDK, verzia 7-8? Najprv by som skúsil rovnakú verziu Javy ako vtedy, keď to funguje. Potom by som pouvažoval nad virtuálom, v Minte by mal stačiť docker, prípadne obyčajný chroot s Debianom.

153
Ano, obrovskou výhodou Gentoo je možnost dlouhou dobu zachovat původní verzi "balíku" (samozřejmě s potřebnými verzemi závislostí), při současném zachování zbytku systému v aktuálním stavu. Případně je možné na jinak stabilní systém nainstalovat nějaký live balík (poslední vývojová verze, v Gentoo označovaná jako 9999). A to vše při zachování konzistence zbytku. To je s jinými distry většinou velmi komplikované (vyžaduje to speciální balíky zkompilovat "růčo" a závislosti si udržovat sám).
Ale je jasné, že na takové to domácí osobní mailíkování je nezbytné mít doma rack se serverem s několika mnohojádrovými xeony, stovkami GB RAM a místo disků SANku. K tomu samozřejmě dvě nezávislé optické přípojky, dva dodavatele elektřiny, obří UPS a diesel agregát. Na tom všem samozřejmě SUSE nebo RH s placeným supportem. Tak je to po javamenovsku a tak je to správné. No co, alespoň se na tom výkon javy skoro přiblíží cěčku na 386ce :D

javamana kľudne môžeš utĺcť po hlave jeho vlastnou lopatou, ale na výkon Javy mi nešahaj. Pokiaľ je pre mňa zložité aby som to napísal v Bashi, tak to urobím v Jave. Urobené to mám hneď, funguje to a je to kupodivu aj rýchle.
Pred veľa rokmi som si v Jave napísal malý interpret Foxky, kupodivu rovnaký kód sa vykonal rýchlejšie v mojom interprete ako v skriplenej VFP od M$ na tom istom železe. Samozrejme Java bežala pod Gentoo a VFP na wydlách, tuším xp/sp2 (sp3 som už nikdy nemal) - to už išla celá ntfs partišna do prepadliska dejín.

Prvý mailserver som mal na FreeBSD už ani neviem ktorej verzie, bolo tam nejaké Pentium asi 133MHz a 64MB SDRAM a frčalo to riadne rýchlo.. Keby na tom M$ pustil ten svoj Excanche, tak sa celkom isto dosere..

Radšej ignoruj túto už zvrhnutú diskusiu a začni písať článok, prípadne seriál, chcem si ho už prečítať, najlepšie ešte dnes.

154
Gentoo a Slackware na server ;D

Už teď se na ten článek těším!


Prečo nie? Gentoo je na server super, beží na ňom presne to čo chceš ty a žiadne iné sprostosti. Samozrejme na začiatok je s ním viac roboty, ale potom si už iba užívaš funkčný a bezproblémový server.

155
Ja som 100% za. Svoj mailserver som si konfiguroval sám na domácom FreeBSD serveri (dovecot, postfix ako osobitný jail, roundcube v jaily spolu s postfixadminom, phpmyadminom a ešte pár webmi) a vtedy by sa mi určite zišiel. Aj teraz si ho rád prečítam a možno sa nechám inšpirovať k nejakým zmenám.

156
Desktop / Re:Video a okno „vždy nahoře“
« kdy: 28. 11. 2016, 18:56:01 »
Na notebooku používam yakuake. Keď mám pustené fillscreen video a stlačím F12, konzola mi normálne vylezie a za ňou ďalej beží video. Flash už pár rokov nepoužívam a ani ho už nikde nemám, takže ma netrápi že je to deravá sračka..a amíkom by som neveril ani nos medzi očami.

157
Desktop / Re:Čím nahradit KDE v Kubuntu 16.04?
« kdy: 25. 11. 2016, 19:57:24 »
Na mojich počítačoch mám už všade KDE5, na Gentoo funguje bez problémov, nič nemrzne, nič nepadá, nikde nemám žiadne centimetrové okraje a už ani žiadne problémy. Na notebooku mám KDE5 dávnejšie, pôvodne ako ~amd64 z overlay, na domácom desktope asi pol roka a niekoľko mesiacov už aj na desktope v práci.
Podľa mňa bol prechod KDE4->KDE5 menej problémový ako KDE3->KDE4, i keď bez nadávok a mlátení do klávesnice sa nezaobišiel.

158
Hardware / Re:Jak často měníte hardware?
« kdy: 11. 11. 2016, 17:21:01 »


zapomel si z IDE->SATA ;)
Sorry, vypadlo mi to asi preto, lebo keď som mal prvú dosku so SATA diskami, linuxový kernel už mal dávno podporu AHCI. Tuším to bola práve vyššie spomínaná Toshiba. Zato všetci M$++ v tých časoch si užili kopec srandy, pretože vtedy bola hlísta ešte v plienkach (aj tak ju nikto nechcel) a pokiaľ nemali emuláciu IDE v BIOSe, naháňali kade-tade po internete všelijaké pochybné drivre, aby to ich deravé xp vôbec nejako nainštalovali.

159
Hardware / Re:Jak často měníte hardware?
« kdy: 11. 11. 2016, 09:27:00 »
Doma mám šesťročný AMD Phenom II X6 1055T + 16 GB RAM, SSD na systém, L2arc a ZIL pre raidz1, dáta sú na platňových diskoch, AMD K9 grafiku. SSD a disky som dokupoval priebežne, grafiku som menil pred 2-3 rokmi, ked som pridal druhý monitor.
Zatiaľ vôbec nepočítam s výmenou procesora a dosky, možno doplním RAM na 32 GB, pokiaľ je ešte DDR3 k diskozícii.
V súčasnosti sú odozvy systému aj programov sú viac ako dostačujúce, v porovnaní s kolegom, ktorý má wydle 10, i7 a 16 GB RAM je môj stroj (aj podľa kolegu) oveľa svižnejší (a aj všetko lepšie vyzerá).
Notebook mám 9-ročnú Toshibu s Dual Core T2370 a 1 GB DDR2, ktorý používam u svokrovcov a doma dvojročné Lenovo E450 s core i3-4005U. Na ňom som si doplnil RAM na 12 GB a vymenil pomalý 500GB HDD za 60GB SSD.
Všade mám Gentoo, vždy je to pôvodná inštalácia asi z roku 2002-2004, ktorú postupne upgradujem z KDE3 cez KDE4, v súčasnosti už mám všade KDE5 (na Toshibe LXQT)

P.S.: by som rád videl ako Jurdo upgraduje wydle xp/sp1 /32bit na wydle 10 /64bit, procesor z Intelu na Amd, grafiku z SIS->NVIDIA->ATI bez reinštalácie systému, samozrejme online počas bežného používania systému. ;D
Tiež by som rád videl ako si urobí tar / partície, rozbalí na druhý disk, nainštaluje zavádzač, vloží do nového PC a do minúty naštartuje pôvodný systém na celkom novom železe.

160
Vývoj / Re:Swap na Raspberry Pi
« kdy: 08. 11. 2016, 20:39:33 »
RPi má 100MBit sieťovku pripojenú cez USB2, to už je rýchlejší slušný flashdisk. Doma mám jeden, ktorý zvládne 50/20MByte/s, má už 5 rokov a asi 2 roky fungoval ako L2ARC na malom FreeBSD serveri s ZFS a je stále bezproblémový. Cacheoval malé súbory a dosahoval asi 5000prístupov/sekundu, čo sa s platňovým diskom proste nedá.
Lepšiu sieťovku (1GBit) má napríklad BananaPi, reálne na nej dosahujem niečo cez 300MBit, takže tiež nič moc, ale je rýchlejšia a takmer nezaťažuje procesor (na rozdiel od RPI).
Takže na RPi by som na swap použil lepší (rýchlejší) flash disk, prípadne partíciu klasického HDD cez USB redukciu - pod Lazarusom by som asi nechcel developovať na SD-karte.
Ak Lazarus iba vyžaduje swap a inak má dosť voľnej RAM, skúsil by som swap na ZRAM, ak ZRAM podporuje kernel.

161
Studium a uplatnění / Re:Uplatnění - Java vs C#
« kdy: 17. 10. 2016, 07:08:19 »
Pokiaľ chceš robiť pre všetky normálne operačné systémy, je tu Java. C# je wydle-only, M$ sa ju snaží pretlačiť všade, ale bez väčšieho úspechu.

162
Server / Re:Pomoc s PHP
« kdy: 09. 10. 2016, 21:21:32 »
Takéto niečo zvládne samotný mysql server, viac o tom je na https://dev.mysql.com/doc/refman/5.6/en/events-overview.html. Samozrejme musí byť mysql server nakonfigurovaný s podporou event shedulera.

163

Ne že bych se považoval přímo za experta, ale o non-PC platformách bych za těch skoro třicet let, od mých začátků na CGS a Didaktiku Gama, měl něco vědět ;)

A v neposledom rade na ruskej hre "Nu pagadi!"

Tu jsem neměl, ale ještě bych přidal programování na TI-57 a něco málo na C=64 :P

Ja som viac expertovejsi  Pocitac Zenit (slovenska obdoba CGS, lenze hi-tech) ->  PMD-85 -> Kalkulator casio FX9600 -> Turingov Stroj -> Stroj RAM -> router "asus blabla s openwrt" mal mips procesor -> rpi 1, 3 a mal som aj tu hru "nu pagadi".

Ale tvrdim, ze java na rpi 1 az 3 je vpohode. Len treba dat oraclovu javu, nie openjdk, no ...

Bohužiaľ na oracle-jdk-bin potrebuješ minimálne RPI2, potrebuješ hardfloat extension, t.j. niečo podobné ako bol voľakedy koprocesor 80387 pre x86 platformu, ktorá na RPI1 chýba. V zadaní bolo RPI2, takže nie je problém.
Áno, TI-57 boli super, mal som bohužiaľ iba TI-57CII, to už bola taká malá plastová hračka.
Na škole sme mali IQ151, to bol podstatne robustnejší počítač, bohužiaľ ani tam Java nefungovala, pretože ešte neexistovala.

164
Pre ARM samozrejme existuje priamo http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html, používam ju na Banana-PI už asi 2 roky. Na SD karte je iba holý systém, dokonca aj jar súbor je v /tmp (tmpfs), banana si appku stiahne pri boote a pravidelne aktualizuje zo servera. Mal som obavy pri nasadzovaní, ale java zaberie počas behu 36MB RAM a rýchlosť je vynikajúca, predčila moje očakávania.
Premýšľal som aj nad inými jazykmi, ale nenašiel som nič, čo by vedelo spoľahlivo a bez problémov komunikovať s M$SQL serverom. Teraz už nad zmenou ani neuvažujem..

165
Vývoj / Re:Paměťová a výpočetní náročnost JVM vs .NET
« kdy: 20. 09. 2016, 22:34:57 »
Už mě to moc nebaví, takže jenom krátce.

Vytvoření pole objektů není žádná optimalizace, je to přímočarý nativní přístup.

Vytvoření pole referencí na objekty je javovina, nic to nepřináší (kromě zjednodušení garbage collectoru), co se týká přístupu do paměti je to neoptimální. Většinou ta neoptimálnost nevadí, pokud ano, je to v Javě problém, protože to nejde normálně vyřešit, musí se to hackovat přes pole primitivních typů, což úplně rozbije datový model a kód v aplikaci.

Nazývat převedení pole referencí na pole objektů předčasnou optimalizací je úplně mimo, pole objektů by měl být nativní přístup, ale není, protože Java...
Tak toto je absolútna <|>vina. Referencie aj objekty sú v Random Access Memory, t.j. v pamäti s ľubovoľným prístupom. Moderné operačné systémy používajú virtuálnu adresáciu pamäte a nikto nezaručí, že časť poľa hodnôt bude v jednej časti fyzickej pamäte a druhá časť nebude celkom inde. Samozrejme platí, že pre procesor sú dáta najrýchlejšie prístupné v poradí register -> L1 -> L2 -> L3 -> RAM -> SWAP. Platí že je vyššia pravdepodobnosť, že pole hodnôt bude bližšie k procesoru (L1, L2,L3) ako keď pôjde o pole referencií, čím by výpočet teoreticky mohol prebehnúť rýchlejšie.
Keďže ale na serveri beží paralelne oveľa viac procesov ako je jadier procesorov, (na mojom serveri je to napríklad teraz 4 jadrá/211 procesov), procesy sa na jednom jadre prepínajú (o to sa stará OS), L1,L2 a L3 sa vyprázdňuje a načítava podľa potreby procesov (o to sa stará správca cache v procesore), pravdepodobnosť toho, že pole hodnôt zostane v cache počas celej práce s poľom je takmer nulová a celá snaha o takúto optimalizáciu nemá žiaden zmysel.
Oveľa väčší zmysel ako sa snažiť o ušetrenie pár nanosekúnd v prístupe k RAM je venovať sa problému, analyzovať ho, zjednodušiť a skrátiť a zrýchliť tým výpočet.
Z celej tejto diskusie mi vyplýva, že pri programovaní v C# sa musí hlavne všetko optimalizovať (keďže to nezvládne za neho OS) a celý jazyk je ako trošku lepší assembler, kdežto v Jave sa sústredím na problém a vyriešim ho tým oveľa rýchlejšie, priamočiarejšie a keďže pri tom nemusím používať všelijaké hacky, tak aj prehľadnejšie pre ostatných.

Stran: 1 ... 9 10 [11] 12 13 ... 41