Hozzászólások
-
Bejegyzés
-
Vasy! Az LFS-be még nekem is beletört a bicskám, pedig én nem vagyok kezdő (mint te). Az még nekem is sok volt.
Vasy! Az LFS-be még nekem is beletört a bicskám, pedig én nem vagyok kezdő (mint te). Az még nekem is sok volt.
LCoder wrote:Semmi. Az eredeti kérdés arról szólt hogy miért éri meg az M$-nek szerver oldalon is terjedni. Egyebek közt ezért is.
Az MS-t egy jó ideje a megalománia irányítja (thx to Steve Ballmer). Inkább szétszórja az erőforrásait, minthogy csinálna kevesebb dolgot, de jól. Az Apple-nek bejött a dolog, egy dologra fúkuszál, és megy is neki. Az MS viszont mindenbe belekap, amibe csak tud (lásd az egyik legnagyobb égése, amikor szuperszámítógépekre akart módosított Windows szervert kiadni, és körbe is röhögték rendesen).A tömörítés valóban javíthat a helyzeten, de a parser akkor is lassabb mint ha bináris lenne. És ettől még vígan meg kell írnod a beolvasót, az OOo ugyanúgy nem olvassa a M$Office 2k7 doksit mint eddig, holott mindkettő xml, ugyanis az egyes tagek jelentése ettől még lehet más.
De a formátum ugyanaz. Nem kell az OOo-nak még egy parsert megírnia, mint meg kellene a bináris formátumhoz.
Amennyire én tudom lekezeli. De én nem vagyok webdesigner, én csak kódot írok, ráadásul ha tehetem nem PHP-ben.
Akkor pozitívan csalódtam, de a WIYSWIYG editorokat sohasem kedveltem…
Nem feltétlenül. Ha egyszer Pistikéből István lesz és profi grafikus akkor az Adobenak jobb ha warezolt PS-t használ mint ha GIMP-et.
Miért is? Anyagilag nem ugyanannyi?
Lehet igazságod, bár ez Mandrake 2005 volt, azaz azért nem időszámításunk előtt…
Az max a Mandrake hülyesége, nekem egy évvel előtte UHU-val ment a dolog…
Azért ennek az esélyét eléggé lecsökkenti hogy ott az ingyenes gecko motor. E mellett (és persze az IE mellett) épeszű cég nem igazán kezd el böngésző motort fejleszteni.
Miért is? Az opera is azt csinálja, és nekik is megy a szekér…
Én nem igazán ilyet mondtam. A nagy nyílt forrású projectek mögött profitérdekelt multik állnak, jól megfizetett profi programozókkal. Az már más kérdés hogy az egyes mezei coderek közt akik lelkesedésből csinálják mekkora a fluktuáció, illetve ezek részaránya is érdekes lehet az egyes projectekben. De az igazi, lelkesedésből csinált open-source projectek elég gyakran pusztulnak ki, lásd Pl. UAE, vagy az igencsak ígéretesen induló vdkbuilder.
Nem nagyon érted a nyílt forrású projektek működését. Először elkezdi pár lelkes ember, aztán mögéáll egy (vagy több) cég. Azon kívül teljesen más egy szoftvert fejleszteni, mint mondjuk pizzát sütni.
Ebben biztos lehetsz. Az AV-nál kikötött pénz ugyanis a M$ pénztárcáját apasztja, jóval intenzívebben mint amit egy AV gyártó fű alatt visszacsúsztathatna. Ráadásul egy amcsi szoftvercég, különösen egy ekkora nem úgy műxik mint a magyar Incorrect Webdevelopent Bt aki minimálbérért egy pincében foglalkoztatja a 8 általánossal rendelkező webfejlesztőt és számla nélkül féláron csináltatja meg vele a webet még soha nem látott cég weblapján M$Word segítségével.
Akkor miért nem implementált már jóval korábban bizonyos alapfokú biztonsági intézkedéseket?
Az M$ vírusirtó nélkül is képes felzabálni bármennyi erőforrást (persze az is igaz hogy az első linuxom óta a 3x 1.44-es lemezes telepítő és a 8MB RAM memóriaigény picit mintha megnőtt volna a desktop linuxokon).
De 512 MB memóriával a Linux olyan sebességen van, mint a Windows 2 GB memóriával ugyanazon a vason… ami azért nem mindegy…
És prüszkölnek is a júzerek rendesen. Amúgy ez a dolog annyira nem új, minden *nix ezt csinálja, és az M$-nek sem az (neki is volt saját unixa a régi szép időkben, xenixnek hívták ha jól emlékszem, és talán ebből lett később az SCO Unix).
Ez kb olyan, mint az autóban a biztonsági öv. Az sem túl kényelmes, de ha nem kenődsz ki a szélvédőn, akkor meg csak jó dolog az.
Úgy hallottam hogy a mezei programoknak nincs gondjuk a 64 bittel, csak a drivereknek.
Csak lassabbak… már amelyikek elmennek. De sok sikert ahhoz, hogy 64 bites gépre 32 bites flashplayert rakj.
Meglátjuk. Picit nekem is furának tűnik az ötlet, de ki tudja… A beszédfelismerő rendszer valóban merész ötlet volt, és őszintén szólva az értelmét sem nagyon látom. Tény hogy a M$-nek időnként vannak fura ötletei (Pl. a VFAT, FAT32, egész win9x vonal, stb. De vannak jó dolgaik is, Pl. a .NET 3 API, bár ott sem értem hogy Pl. miért maradt ki a WPF-ből a datagrid, ez kb. olyan kérdés mint hogy miért nincs a javában property…
Az MS nagyon jó vaporware gyártásban (lásd WinFS, Singularity vagy a Vista fícsörjei, aminek a fele kimaradt), meg hülyeségekre is tud ám ezerrel mesterséges igényeket gerjeszteni.
A java-ban nincsen property, mert felesleges (újabb „innováció” by MS).LCoder wrote:Semmi. Az eredeti kérdés arról szólt hogy miért éri meg az M$-nek szerver oldalon is terjedni. Egyebek közt ezért is.
Az MS-t egy jó ideje a megalománia irányítja (thx to Steve Ballmer). Inkább szétszórja az erőforrásait, minthogy csinálna kevesebb dolgot, de jól. Az Apple-nek bejött a dolog, egy dologra fúkuszál, és megy is neki. Az MS viszont mindenbe belekap, amibe csak tud (lásd az egyik legnagyobb égése, amikor szuperszámítógépekre akart módosított Windows szervert kiadni, és körbe is röhögték rendesen).A tömörítés valóban javíthat a helyzeten, de a parser akkor is lassabb mint ha bináris lenne. És ettől még vígan meg kell írnod a beolvasót, az OOo ugyanúgy nem olvassa a M$Office 2k7 doksit mint eddig, holott mindkettő xml, ugyanis az egyes tagek jelentése ettől még lehet más.
De a formátum ugyanaz. Nem kell az OOo-nak még egy parsert megírnia, mint meg kellene a bináris formátumhoz.
Amennyire én tudom lekezeli. De én nem vagyok webdesigner, én csak kódot írok, ráadásul ha tehetem nem PHP-ben.
Akkor pozitívan csalódtam, de a WIYSWIYG editorokat sohasem kedveltem…
Nem feltétlenül. Ha egyszer Pistikéből István lesz és profi grafikus akkor az Adobenak jobb ha warezolt PS-t használ mint ha GIMP-et.
Miért is? Anyagilag nem ugyanannyi?
Lehet igazságod, bár ez Mandrake 2005 volt, azaz azért nem időszámításunk előtt…
Az max a Mandrake hülyesége, nekem egy évvel előtte UHU-val ment a dolog…
Azért ennek az esélyét eléggé lecsökkenti hogy ott az ingyenes gecko motor. E mellett (és persze az IE mellett) épeszű cég nem igazán kezd el böngésző motort fejleszteni.
Miért is? Az opera is azt csinálja, és nekik is megy a szekér…
Én nem igazán ilyet mondtam. A nagy nyílt forrású projectek mögött profitérdekelt multik állnak, jól megfizetett profi programozókkal. Az már más kérdés hogy az egyes mezei coderek közt akik lelkesedésből csinálják mekkora a fluktuáció, illetve ezek részaránya is érdekes lehet az egyes projectekben. De az igazi, lelkesedésből csinált open-source projectek elég gyakran pusztulnak ki, lásd Pl. UAE, vagy az igencsak ígéretesen induló vdkbuilder.
Nem nagyon érted a nyílt forrású projektek működését. Először elkezdi pár lelkes ember, aztán mögéáll egy (vagy több) cég. Azon kívül teljesen más egy szoftvert fejleszteni, mint mondjuk pizzát sütni.
Ebben biztos lehetsz. Az AV-nál kikötött pénz ugyanis a M$ pénztárcáját apasztja, jóval intenzívebben mint amit egy AV gyártó fű alatt visszacsúsztathatna. Ráadásul egy amcsi szoftvercég, különösen egy ekkora nem úgy műxik mint a magyar Incorrect Webdevelopent Bt aki minimálbérért egy pincében foglalkoztatja a 8 általánossal rendelkező webfejlesztőt és számla nélkül féláron csináltatja meg vele a webet még soha nem látott cég weblapján M$Word segítségével.
Akkor miért nem implementált már jóval korábban bizonyos alapfokú biztonsági intézkedéseket?
Az M$ vírusirtó nélkül is képes felzabálni bármennyi erőforrást (persze az is igaz hogy az első linuxom óta a 3x 1.44-es lemezes telepítő és a 8MB RAM memóriaigény picit mintha megnőtt volna a desktop linuxokon).
De 512 MB memóriával a Linux olyan sebességen van, mint a Windows 2 GB memóriával ugyanazon a vason… ami azért nem mindegy…
És prüszkölnek is a júzerek rendesen. Amúgy ez a dolog annyira nem új, minden *nix ezt csinálja, és az M$-nek sem az (neki is volt saját unixa a régi szép időkben, xenixnek hívták ha jól emlékszem, és talán ebből lett később az SCO Unix).
Ez kb olyan, mint az autóban a biztonsági öv. Az sem túl kényelmes, de ha nem kenődsz ki a szélvédőn, akkor meg csak jó dolog az.
Úgy hallottam hogy a mezei programoknak nincs gondjuk a 64 bittel, csak a drivereknek.
Csak lassabbak… már amelyikek elmennek. De sok sikert ahhoz, hogy 64 bites gépre 32 bites flashplayert rakj.
Meglátjuk. Picit nekem is furának tűnik az ötlet, de ki tudja… A beszédfelismerő rendszer valóban merész ötlet volt, és őszintén szólva az értelmét sem nagyon látom. Tény hogy a M$-nek időnként vannak fura ötletei (Pl. a VFAT, FAT32, egész win9x vonal, stb. De vannak jó dolgaik is, Pl. a .NET 3 API, bár ott sem értem hogy Pl. miért maradt ki a WPF-ből a datagrid, ez kb. olyan kérdés mint hogy miért nincs a javában property…
Az MS nagyon jó vaporware gyártásban (lásd WinFS, Singularity vagy a Vista fícsörjei, aminek a fele kimaradt), meg hülyeségekre is tud ám ezerrel mesterséges igényeket gerjeszteni.
A java-ban nincsen property, mert felesleges (újabb „innováció” by MS).Kezdem én a referenciázást: http://yorirou.nwi.hu
Kezdő cucc, nem annyira rossz a HTML rész (bár vagy 2 éve írtam a motort, azóta csak apróbb javításokat eszközöltem, meg beleraktam egy admin felületet).
Amire büszke leszek, az az új motor (készülőben van; jelenleg a keret megvan, már csak a modulokat kell belefejeszteni), SMARTY-val, és ott lesz arra lehetőség, hogy könnyen olvasható, szépen strukturált XHTML 1.0 Strict dokumentumot generáljak.Vasy: most te jössz a referenciákkal. Mutass olyan oldalt, amit te készítettél!
A kérdést felvetőnek: a Gentoo egy külön állatfaj. A kaland garantált és a rengeteg új ismeret is, de kell pár alap dolog, ami ha nincs meg, bele se kezdj:
– értőolvasás, tehát nem felismered a betűket, hanem megérted, hogy mit akarnak írni
– angol nyelvtudás
– ismered a Linux felépítését és az alapvető parancsokat
– van időd foglalkozni a rendszerrel (van olyan, hogy rá kell szánni pár órát egy program frissítése után, hogy menjen)
Ha ezek megvannak, és megkötsz pár kompromisszumot (időbe telik felrakni egy programot; nem sok minden van készen, tehát ahhoz, hogy valamit be tudj lőni, alap szinten meg kell ismerni a működését… néha kellemetlen tud lenni (pl.: ALSA), de egyszer elég megcsinálni), akkor jönnek az előnyök:
– sebesség (kevesebb mindent fordítasz bele, így kevesebb library-t kell betölteni a memóriába; a CFLAGS gyorsít összességében ~10%-ot, de bizonyos alkalmazások esetén (médialejátszók, grafikai programok) akár két-háromszor akkora teljesítményt érhetsz el modern processzorokon, mintha ugyanazon gépre i486-os csomagot raknál))
– rugalmasság (USE flagek)
– rengeteg csomag (most már könnyű az overlayeket használni)
– a te kezedben van minden irányításGyors közbevetés: érdemes-e szoftveres renderrel berylezni? Hardveres renderem olyan szinten van, hogy a VESA driver is jobban áll az ügyben.
A HTML objektumodból a CSS-re class-sal hivatkozol. Fontos, hogy jó neveket adj, és minimalizáld annak az esélyét, hogy rossz helyen kerül felhasználásra az adott class. Kerüld az olyanokat, hogy:
Code:div.menu{
…
}div.menu2{
…
}Ezekkel hosszú távon csak szívni fogsz. Mivel a HTML egy strukturált objektumfa, ezért használd ki az előnyeit (ez most bonyolultan hangzott, de mindjárt megvilágítom egy egyszerű példával). Tegyük fel van egy oldalad, ami hasonlóan néz ki, mint most az lfhu. Van egy felső és egy oldalsó menüsávod. A felső menüsáv egy divben van benne a fejléccel együtt, az oldalsó menüsáv pedig külön, illetve a „tartalom” rész is egy külön div. Ebben az esetben ez a rossz megközelítés:
Code:div.menu_felso{
…
}div.menu_oldalso{
…
}Ez a jó:
Code:div.felsodiv div.menu{
…
}div.menu{
}
Ezzel egyértelműsíted, hogy miről van szó, és utólag könnyebb lesz átlátni, hogy mi mire vonatkozik.
Az átláthatóságot növeli az is, hogy ha az elavult HTML helyett a sokkal modernebb XHTML-t használod. Abból is a strict-et, mert megtanulod általa hogyan kell jól strukturált dokumentumot szerkeszteni/generáltatni.vizsla wrote:az eltávolítása súlyos és kijavíthatatlan károkat okoz.
=> nincsen hozzá uninstall (ergo nem lehet hiba nélkül eltávolítani)
