Új hozzászólás Aktív témák

• #72 ddekany veterán

  Új Válasz 2012-01-02 16:59:48 #72

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  Én már úgy egy éve LibeOffice-t használok MS Office 2000 (nem mai darab!) helyett, pont hogy teszteljem, mennyire lehet ajánlani másoknak. A benyomásom pedig, hogy az MS Office 2000 simán kiforrottabb, gyorsabb, és kevésbé bugos mint a 2010-es LibreOffice. Ezen kívül az MS Office kompatbilitás is annyira igaz, mint minden más ebben a szakmában (tehát kamu, a felületes szemlélő megtévesztésére). Ha pl. ilyen futurisztikus funkciókat használ valaki, mint hogy képeket szúr a szövegbe körbefolyatósan, akkor ott szép eltérések lehetnek. Szóval ha nem valami teljesen alap dokumentumról van szó, nem kompatibilis.

  Most ezzel nem azt mondom, hogy baj, ha erőltetik az áttérést... minél többen használják, remélhetően annál több fog jutni a fejlesztésére is, meg annál kevésbé lesz kérdés a kompatibilitás (mert a forrás is LibreOffice). Csak ne legyenek senkinek sem illúziói, jelenleg vannak itt eltérések az ikonok helylén kívül is... Más szóval, ha nekem nagyon nagy szerepe lenne a munkámban a Wordnek (és nem lennék ODF-re kötelezve), én inkább fizetnék érte, mintsem LibreOfficot használjak.

  [ Szerkesztve ]

• #77 ddekany veterán ArchElf #74

  Új Válasz 2012-01-02 17:09:39 #77

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz ArchElf #74 üzenetére

  Mellékesen jegyzem csak meg, hogy itt brutális űrt hagyott a szakma... Szakdolgozatot írni Wordben... lehet, de az egész megközelítése ezeknek a szövegszerkesztőken alkalmatlan erre. Léteznek ugyan értelmesebb sémák (LaTeX, DocBook, DITA, stb), de ezeket halandónak való eszközökkel sokkal jobban meg kéne támogatni, hogy alternatívák legyenek miden napos használatra. (Most az (elit-)programozókat hagyjuk... külön állatfaj , extrém tűréshatárokkal.)

• #116 ddekany veterán attila9988 #96

  Új Válasz 2012-01-02 23:55:43 #116

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz attila9988 #96 üzenetére

  "Nehogy azt mond hogy nincs megfelelő szerkesztő latex -hez... Még ha azt mondtad volna hogy tex -hez. Én a texmakerx -et szeretem a legjobban"

  Őszintén, régen futottam ezzel köröket már komolyabban, szóval javítsatok ki egy konkrét termékkel, ha tévedek. De bármi ami nem elsődlegesen WYSIWYM (what you see is what you mean) kapásból kiesett... azért, mert ha dokumentáció szerzésről van szó, a forrás szintű szerkesztés a tipikus terminálagyú mazó-sötétség egy igen jó példája. Nyilván, ha nincs értelmes magasabb szintű eszköz, akkor az ember forrás szinten szerkeszt, csak látni kéne, hogy ez a szituáció szar. Aztán persze ott van a LyX, ami alapmegközelítésében értelmesebb, csak legalábbis legutóbb mikor láttam, pl. nem volt benne gépelés közbeni helyesírás ellenőrző, és HA ez még mindig úgy van, az kapásból bukás, lévén az egy szövegszerkesztő akarna lenni. Mármost lehet mondani, hogy ezek akkor sem múlják alul a Word-öt... Nagyobb folyamatosan karbantartott dokumentációnál persze hogy nem, de ezzel ugye nem mondtunk sokat, meg ez kevés a tömegesebb sikerhez. (Én jelenleg amúgy technikai dokumentációhoz XXE felé húzok... csak aztán ugye old meg hogy értelmes kimenet is legyen abból az XML-ből. Főleg ha saját/bővített XML sémát használsz. Meg persze nincs magyar helyesírás ellenőrzője... és nem túl olcsó, ha értelmes verziót akarsz.)

• #117 ddekany veterán sh4d0w #99

  Új Válasz 2012-01-02 23:59:44 #117

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz sh4d0w #99 üzenetére

  Annyira nem kell rajta röhögni... mert az MS Office és a LibreOffice közti minőség különbség (MS javára) azért aligha vitatható. Nyilván, a LibreOffice-hoz viszont nem kell vagyonért licencet venni. Csak ez nem mindenkinek éri meg. Annyiban lehet reménykedni, hogy ha erőltetik a LibreOffice-t sok-sok helyen, akkor előbb-utóbb kikupálódik.

  [ Szerkesztve ]

• #153 ddekany veterán bambano #119

  Új Válasz 2012-01-03 11:33:06 #153

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz bambano #119 üzenetére

  "sosem értettem azokat, akik egyszer láttak már xml szabványt és attól kezdve mindent xml-ben látnak. visítva menekülök az xml-től..."

  Említett XXE esetén sehol nem látsz forrás szinten XML-t, az "infosetje" (az adat struktúra amit tárol) az XML-nek pedig pont hogy jó, és nem is tudnék mondani formátumot, ami ott versenyképes vele. Tehát ha csak az utóbbit kapod az arcodba (a strukturált adatot), akkor pont az XML jó oldalát kapod.

• #160 ddekany veterán attila9988 #130

  Új Válasz 2012-01-03 11:55:43 #160

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz attila9988 #130 üzenetére

  "Na ez egy hatalmas tévedés. Egy latex kód alap esetben tökéletesen áttekinthető"

  Most mit mondjak erre. Ezért tartunk itt, ahol. Látni kéne, hogy a kézben tarthatatlan WYSYWYG és forrás szintű szerkesztés közt azért lenne egy átmenet. Mikor tisztán szemantikailag szerkesztesz (pl. egy cím mindig ugyan úgy néz ki, attól függetlenül hogy a kimenetben hogy néz majd), de nem valami markupot nézel, hanem valamit, amit emberi agyra optimalizáltak. Dokumentum írásnál a legtöbb szemantikai elemet remekül ki lehet fejezni kihagyásokkal, betűméretekkel, stb... maradékra bedobhatsz ikonokat vagy kis cimkéket meg dobozokat a dokumentumba. Nyilván, ez dokumentumokra vonatkozik, nem általában minden adatstruktúrára. (Bár, JetBrains próbálkozott a program forráskód szerkesztést is ilyen irányba vinni, és szerintem lenne abban is potenciál, de nyilván a programozók élből elutasítanák.)

  "Az xml meg tényleg kényelmetlen, de ha neked az kell, akkor miért nem docbook? No mindegy, bár abból lehet pl latex -be exportálni. "

  Ha forrás szinten szerkeszted, akkor borzalmas, de én olyat nem csinálok... Ha figyelsz, én XXE-t mondtam. És azzal pont hogy DocBook-ot meg DITA-t szokás szerkeszteni. A LaTeX-be import (vagy talán inkább TeX-be) meg nem hülyeség, mert van egy kiforrot tördelője, és nem mond ellent az XML használatnak, hisz annak pont ez a logikája, hogy "külső" programmal csinálsz belőle kimenetet (mondjuk jellemzően XSL-el, de semmi nem kötelez rá).

  (Mellékesen jegyzem meg, hogy az egész web lényegében XML-ből van. Tudom, inkább valami SGML elfajulás ha nem XHTML, de ugyan úgy szívás szerkeszteni. A kitalálók talán arra számítottak, hogy valami dreamweaver szerűséggel szerkesztjük majd, de hát annyira div-káosz hacklés lett az egészből, hogy értelmét vesztette az az irány...)

  [ Szerkesztve ]

• #178 ddekany veterán attila9988 #164

  Új Válasz 2012-01-03 13:57:46 #178

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz attila9988 #164 üzenetére

  "Még annyit hogy az xmlmind egyik nagy baja, hogy lassú mint a tetű, és zabálja a ramot. De ez a java miatt van"

  Khm... C/C++ után szorosan a 2. leggyorsabb széles körben használt nyelv, gondolom C#-al együtt. RAM-ot eszik rendesen (GC és sok-sok objektum... ezzel sokat nem lehet kezdeni), de mondjuk sok giga RAM melett mindegy. Meg Java alkalmazásnál meg kell várni, amíg elindul. Ennyi kb.

  Szóval ha használat közben lassú, akkor azért mert a késztők nem foglalkoznak eleget az optimalizálással (vagy simán túl komplex a probléma). De nálam 200 A4 oldalas DocBook szerkesztése esetén ősi 2 Mhz-s Core2-vel jól használható.

• #180 ddekany veterán bambano #170

  Új Válasz 2012-01-03 13:59:55 #180

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz bambano #170 üzenetére

  "ha neked a nyomjuk meg 5x a ctrl+up nyilat felhasználói élmény meg követendő út, akkor kövesd"

  Nem gondolom, hogy az XXE átlag felhasználónak való az egyedi szerkesztési módjával, de egyébként szerintem igen is jól használható ha kitanulod. És nem vagyok mazó, szóval... na.

• #183 ddekany veterán attila9988 #171

  Új Válasz 2012-01-03 14:11:11 #183

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz attila9988 #171 üzenetére

  "Ezért nem lehetnek azonos programlogikát feltételezve soha olyan gyorsak, mint egy C-ben írt program. Hiszen az, amit a C esetén a fordító eldönt egyszer, és a gépi kódú programot leírja egy állományba, azt az értelmezett nyelvek fordítójának menet közben kell megtennie"

  De csak 1x fordítja le a Java byte-kódot natívra a JIT. Ezért (is) persze lassan indul a Javas alkalamzás, de aztán ha "bemelegedett" már nincs további veszteség ebből.

  "menet közben kell megtennie, és sok optimalizációt el sem végez"

  Ez sem ilyen egyszerű. Egyrészt, igen, nincs annyi időt rágódni optimalizációkon mint mondjuk a gcc C/C++-fordítójának. Másfelöl viszont futás időbe olyan információk állnak rendelkezésedre, ami fordítás időben nem. Pl. az optimalizáció át tud "járni" a könyvtárak határán (mert már be vannak linkelve), lehet a program tényleges futása közben statisztikákat készíteni, stb. Ja, és mellékesen az, hogy nincs pointer aritmetika, olyan automata optimalizációkat tesz lehetővé, amik amúgy nem lennének biztonságosak (míg persze, a pointeres kavarások C/C++-ben értékes kézi optimalizációra adnak lehetőséget... csak aztán jön a buffer alúl/felül csordulás meg a sok malware ami azon él).

• #186 ddekany veterán MichaelSD #182

  Új Válasz 2012-01-03 14:14:53 #186

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz MichaelSD #182 üzenetére

  "Az MS megoldásai valóban jobbak, ha kihasználod a benne rejlő lehetőségeket."

  Meg anélkűl is, ha a Word-ről beszélünk... Ez van. Ettől még megérheti hosszú távon, csak ne legyenek illúzióink.

• #210 ddekany veterán attila9988 #199

  Új Válasz 2012-01-03 15:45:48 #210

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz attila9988 #199 üzenetére

  "Node fordított kódnál nem is kell jvm -hez hasonló valami sem"

  Na, hát erre van pl. a D. Modern, de nem kell hozzá VM. Persze nem bír felfutni... Amúgy azért kell a natív programok alá egy kernel meg rakás könyvtár, csak ezt természetesnek vesszük, hogy már ott van, míg a JVM kénytelen ezeken felül ott lenni.

  "illetve a gc sem, ami megenné a memóriát."

  A GC egy nehezen megkerülhető dolog. Az van, hogy a messze leggyakrabban használt erőforrások amit nyitni/csukni kell, azok a memória cafatok. Ráadásul sokszor állatira nem triviális, hogy mikor lehet őket "csukni", ellenben egy tipikus file handle-vel. Ettől minimum, hogy baromira idegesítő vállik őket pesztrálni, meg főleg olyan nincs, hogy ne cseszd el rakás helyen egy nagyobb programban (és lőn memory leaking, vagy még rosszabb). Ezért lényegében minden modern nyelv GC-zik. Ebből nem is lenne akkora RAM pocséklás tán, ha a GC OS szinten valósulna meg, nem úgy, hogy mindegyik kis virtuális gép a sajátját lufi heap-jét hízlalja. Persze akkor még ott vannak a GC pause-ok, főleg nagy heap-nél (mint pl. egy OS szintű...) mint korunk kihívása. Az élet nem egyszerű.

  "a C meg megmarad azokra a feladatokra"

  Egyébként az is mekkora szívás... Könnyebben protolható, meg könnyebb más nyelvekből hívogatni mint a C++-t, szóval van hogy rá vagy kényszerülve, de... ó anyám borogass. Nincs OOP támogatás, nincs kivétel kezelés, nincs semmilyen segítség memória kezelésre (smart pointerek, RIIA), stb... Őskövület borzalom. És ha még csak kerneleket írnának benne, de hát fenti okokból közel sem...

• #215 ddekany veterán attila9988 #211

  Új Válasz 2012-01-03 17:01:16 #215

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz attila9988 #211 üzenetére

  "Mellesleg C -ben nem feltétlenül kell egy rakás alap"

  Ha alkalmazásokról beszélünk, akkor de. Csak hát a kernel és gyakran használt C könyvtárak már eleve be vannak töltve.

  (GC) "És zabálja a memóriát, és a cpu időt."

  A memóriát eszi jobban. De CPU időben általában takarékosabb mint a hagyományos heap kezelés, mert ritkán takarít de akkor nagyot és hatékonyan. Viszont ekkor megakaszt dolgokat kis időre, ami pl. játékban/multimédiában gáz lehet.

  "Egyébként OS szinten hogy oldanád meg a GC -t ha egyszer a java vm -en fut a programod?"

  Ha a kernel szolgáltatásai közt lenne GC-s heapben foglalás, akkor azt hívná a VM a saját megoldása helyett.

  "A nyelv hatékonysága abból is fakad, hogy úm. "nincs kinyalva a programozó segge""

  Csak épp a C++ sebessége a kinyalással (ami mondjuk elég reszelős nyelvvel történik... nem épp Java/C#) együtt is közel ugyanakkora. Nyilván nagyon de nagyon kritikus részeken csínján bánsz egyes C++ képességekkel. Én azt mondom, a C mai napig tartó elképesztő népszerűségében nem kicsi a szerepe a kőagyúságnak meg FUD-nak. Egyszerűen nem igaz, hogy ennyien kernelt írnak, meg erősen megszorításos beágyazott cuccokat.

  "Persze ha kell gyorsan valami server program, akkor nyilván java -ban állnak neki"

  Amúgy a Java az webes szerver programozásban pont az alacsony szintű de viszont állati gyors kategória. De nem kicsit a leggyorsabb, hanem messze... Na persze, ott napi 24 órában fut ugyan az a JVM, és darálja ezresével a látogatókat. Kis oldalnál meg unatkozna napi 24 órában egy kupac RAM tetején, szóval oda nem jó.

  "Azért mutathatna nekem valaki olyan desktop -ra vagy arra is szánt java -s cuccot, ami nem lassú mint a tetű."

  Kellene egy C/C++ egyenértékű alkalamzás amivel összevetem... Anélkül nehéz ítélni. Ja, indulási idő nem ér, az beismerten tetű.

• #216 ddekany veterán attila9988 #211

  Új Válasz 2012-01-03 17:11:52 #216

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz attila9988 #211 üzenetére

  "Ha a programozó gondoskodik ezekről a dolgokról, akkor nem kell gc -zni. Persze könnyebb programozni ha kevesebb dologra kell figyelni."

  A programozással az a baj, hogy általában mindig lehetne még min dolgozni, soha sincs vége... Tehát nem tudsz úgy áldozni valamire időt, hogy ez ne menjen valami más funkcionalitás rovására. Dönteni kell... Memória kezeléssel akarsz tökölni, vagy inkább ahelyett beteszel +N fícsört, esetleg mást optimalizálsz.

Új hozzászólás Aktív témák