Webserver windows-hoz
2010-05-16T02:57:28+02:00
2010-05-19T11:57:04+02:00
2022-07-25T03:12:31+02:00
  • "Ráadásul, nem feltétlenül gondolom, hogy nem lett volna olcsóbb (és itt most nem kimondottan pénzre gondolok) megoldás, pl.: nagyobb merevlemez beszerzése (ha kell) vagy felhasználói kvóta beállítása (mint minden feltöltésnél keresni, összehasonlítani, ellenőrizni)."

    Pénzügyi szempontból kifizetődő volt a dolog, mert a rendszer karbantartásáért és a support-ért havi fix összeget utal a megrendelő még akkor is, ha éppen semmi dolog sem volt vele. Még a napi biztonsági mentést is cron-nal automatizált mechanizmus végzi, azaz még ezzel sem kell "bajlódnunk" naponta. Így a feladat azért volt pénzügyileg kifizetődő, mert a megrendelő a módosítási költségeknek már a többszörösét is befizette a havi rendszerességű átutalásaival.

    A nagyobb merevlemezes megoldás lett volna a legegyszerűbb, de ez messze nem olyan hatékony, mint a mi megoldásunk. Mert ha az is kezd betelni, akkor megint újabbat kell venni, illetve berakni azt a RAID tömbbe. Ez ugyan nem nagy munka, de felhasználói hülyeség (nem szükséges feltöltések berögzött elvégzése) ellen nem véd.

    Van felhasználói kvóta, de ezek a megrendelő kérésére egyelőre inaktiválva vannak (a megálapodás szerint csak akkor kell a kvótát élesíteni, ha azt a megrendelő is szükségesnek ítéli meg, de egyelőre még nagyon nem akarja, vitatkozni meg senki sem akar vele).

    A keresés/összehasonlítás/ellenörzés úgy történik, hogy minden ténylegesen lementésre (azaz nem linkelésre) kerülő fájl MD5 kulcsa a fájl eredeti és letárolt nevével és elérési útjával együtt egy erre szánt adatbázistáblában tárolásra kerül. Amikor új feltöltés érkezik, akkor annak MD5-je SQL művelettel (villámgyorsan) kikeresésre kerül a táblából ahelyett, hogy minden fájlt egyessével át kellene nyálazni. Ráadásul nem csak MD5-, hanem saját fejlesztésű hash is ugyanígy tárolva/keresve van, ami szinte 0-ra csökkenti annak esélyét, hogy két különböző fájl MD5 kulcsa azonos legyen. A megoldás így az SQL jóvoltából gyors is, és a dupla hash-elés végett biztonságos is.


    Szerk.:
    Visszatérve az eredeti témára: Én (sok más ok miatt is) azért nem használok Windows-t, és így ezért nem azon tesztelek, mert már sok oldal-, bonyolultabb/összetettebb rendszer megépítésében kivettem a részem, és eddig mindössze egyetlen alkalommal találkoztam Windows-zal a szerveren; az összes többi helyen kivétel nélkül mindig Linux volt. Ezért nekem az az egyszerűbb, hogy ugyan úgy Linux-on fejlesztek, mivel így kisebb az esélye, hogy a célrendszer a tesztelttel ellentétben furcsaságokat műveljen, és mindezt az op.rendszerek inkompatibilitásából adódóan. Persze lehet Windows-on is jól fejleszteni (pont ezt csinálod te is), de mivel én amúgy is mindig Linux-ot használok, így nem lenne értelme fejlesztéskor Windows-oznom. Így természetes, hogy webszervert is Linux-ra telepítek, nem Windows-ra.
    Mutasd a teljes hozzászólást!
  • Hali!

    ...nem tud(hat)om, hogy mennyire használják ezeket mainstream, de az biztos, hogy nekünk nagyon jól jött a hardlink-kelési lehetőség.


    Így van, megoldottátok - első olvasatra ügyesen - a problémát. De ettől még ez nagyon kis százalékban használt lehetőség - szerintem. Ráadásul, nem feltétlenül gondolom, hogy nem lett volna olcsóbb (és itt most nem kimondottan pénzre gondolok) megoldás, pl.: nagyobb merevlemez beszerzése (ha kell) vagy felhasználói kvóta beállítása (mint minden feltöltésnél keresni, összehasonlítani, ellenőrizni).

    Mutasd a teljes hozzászólást!
  • Hali!

    A symlinkek nagyon leegyszerűsítik a fejlesztést.


    Elfogadom, hogy van olyan eset, amikor igen. Persze, én nem használok symfonyt, így nekem még nem jött elő.

    Én úgy gondolom, hogy sokkal egyszerűbb úgy fejleszteni, hogy csak kisbetűs (vagy nagybetűs - ízlés kérdése) fájlneveket használsz (ékezetek, speciális karakterek nélkül), nincs vele gond. Persze, nem vagyunk egyformák...

    Használok linuxot, de nekem a Windowson történő fejlesztés - valahogy' - gördülékenyebbnek tűnik. Biztosan lehetne "szórakozni" Windowsos eszközök linux alatt futtatásával (notepad2, PSPad még talán működne is - nem próbáltam), de ennek nem látom értelmét. Adobe termékeket meg amúgy is használok (sitebuild-re, dizájnra is, de elsősorban DTP-s munkákra), így marad a Windows (megjegyzem, én sem tekintem a PS-ot PHP-eszköznek, nem is említettem ilyesmi).

    Természetesen, mindenki azt használ, amit akar. Én csak megjegyeztem, hogy nekem még soha nem volt abból problémám, hogy Windowson fejlesztettem, és linuxra került a kész produktum.

    Mutasd a teljes hozzászólást!
  • "Én csak arra lennék kíváncsi, hogy ezeket a link()... dolgokat mennyire használják "mainstream"?"

    Erre csak egy saját példát tudok mutatni; tanulságos lesz...

    Van egy olyan rendszerünk, amely egy pénzintézet különböző külterületi képviseleteit fogja össze közös rendszerbe. Ebben kismillió más szolgáltatás mellett van olyan is, hogy a bejelentkezett felhasználóknak lehetőségük van fájlok feltöltésére (persze meghatározott korlátozások és szigorítások betartásával, csak a saját könyvtárukba). Amikor a rendszert intenzíven elkezdték használni, akkor két hónap után arra lettünk figyelmesek, hogy drasztikusan csökken a rendelkezésre álló tárhely a szerveren. Megvizsgáltuk ennek az okát, és mint kiderült azért van ez, mert igen sok dokumentumot töltenek fel a felhasználók a szerverre. Ezek többnyire szolgálati rendeletek Word dokumentumai, meg XLS táblái, amelyeket minden érintett felhasználó email-ben megkap, majd szokásukhoz híven fel is töltik (pedig ez nem volna kötelező). Ezen dokumentumok a gyakorlatban ugyan azok, csak sok-sok példányban feltöltve az egyes felhasználók álltal.

    Ekkor jött az ötlet, hogy linkesítsünk. Átírtuk a feltöltő modult olyanra, hogy az a feltöltés után (amikor még a /tmp-ben "landol" a fájl), akkor a rendszer kikeresi a már korábban feltöltött fájlokból, hogy van-e köztük olyan, amely tartalmilag bájtról bájtra ugyan azt tartalmazza, mint a frissen feltöltött dokumentum. Ha nem talál ilyet, akkor ténylegesen elvégzi a végleges tárolási helyre való másolást, de ha talál ilyet, akkor csak egy hardlink-et tesz a felhasználó orra elé, amely a már korábban más által feltöltött példányra mutat.

    Így a felhasználó később nyugodtan törölheti a feltöltését, mert az op.rendszer linkszámlálója biztosítja, hogy fizikailag csak abban az esetben legyen törölve a fájl, ha már egyetlen másik egyéb hivatkozás sem mutat rá. Illetve az sem okoz gondot, ha az egyes azonos tartalmú feltöltéseket a felhasználók különböző fájlnevekkel végzik el, mert ugye a hardlink neve tetszőleges lehet, ettől még a tényleges fájlhivatkozás nem változik.

    A végeredmény az lett, hogy a felhasználók semmit sem vettek észre az átalakításból (hiszen előttük ugyan úgy megjelennek a feltöltött fájljaik ikonjai), és mi is örülhettünk, mert a trükk alkalmazásával a szükséges tárhely az eddigi 1/6-ára csökkent le.

    Szóval a kérdésedre válaszolva: nem tud(hat)om, hogy mennyire használják ezeket mainstream, de az biztos, hogy nekünk nagyon jól jött a hardlink-kelési lehetőség. És ez csak egyetlen gyakorlati példa volt, de talán te is tudnál hasonlóra példát mondani. Hidd el, nem olyan rossz találmány az a link...
    Mutasd a teljes hozzászólást!
  • "Te ilyen nagyon linux gurunak látszol."

    Pedig hidd el, nem vagyok az. Nálam vannak sokkal okosabbak is, és időnként megesik, hogy a mai napig kérdeznem kell, ha valami nem elég egyértelmű számomra a man oldalak olvasgatásával sem. Inkább hívnám magam Linux felhasználónak, mint gurunak.

    "Valaki használ linuxot jó, de miért kell és hangsúlyozom KELL másokra is rátukmálni?"

    Ezzel én sem értek egyet. Pont az a lényeg, hogy a felhasználó maga dönthessen, hogy mely rendszert kívánja használni, nem szabad rábeszélni senkit sem egyikre vagy másikra. Én gyakran szoktam hangot adni a Linux mellett véleményeimnek különböző fórumokon, de ezeket mind akkor teszem, ha valami Linux-gyalázó írást olvasok, és ezt is csak akkor, ha valóban nem jogos, ami le van írva. De nem szoktam senkire sem rátukmálni, inkább csak felvilágosítani szoktam, hogy nem olyan rossz az, mint amilyennek egyesek állítják. És a döntést (hogy kipróbálja-e) rá bízom.

    "Valami komolyabb különbség a két php között esetleg van? [..] Mindazonáltal komolyabb eltérő módon működő függvényről még nem láttam de nem is hallottam."

    Most konkrétan nekem sem jut eszembe ilyenre példa, csak olyanok, amelyek a PHP mögötti op.rendszer sajátosságaiból fakadnak.
    Mutasd a teljes hozzászólást!
  • Igen, sokáig én is így hittem, de ma már nem vagyok ebben olyan biztos. Mert ha a kis/nagybetű érzéketlenség annyira jó, akkor miért nem alkalmazza ezt a legtöbb operációs rendszer illetve programozási nyelv?

    1. A két dolog nincs összefüggésben egymással. Ti. az, hogy N darab nyelv vagy OS nem így működik, abból nem következik az, hogy az amelyik viszont mégis, az ne tudatos tervezés - urambocsá esetleg logikus megfontolás - eredményeként tenné ezt.
    2. A "legtöbb" állítás nem igaz, sőt, kisebbségben vannak - és az elmúlt három évtizedben végig voltak is - azok az operációs rendszerek (piaci részesedés alapján mindenképpen), amelyek megkülönböztetik őket. Nyelvek esetén szintén erősen megoszlanak az oldalak, olyan hibridekről nem is beszélve, mint pl. a PHP, amiben a függvény- és metódusnevek nem kis-/nagybetű-érzékenyek, míg a változó és konstansnevek azok.
    3. Vegyük észre, hogy nem a kis-nagybetű megkülönböztetése, hanem a meg-nem-különböztetése az ami plusz kódot és feldolgozást igényel (ti. bináris helyett szöveg-alapú összehasonlítás kell, ami ráadásul nem is olyan egyszerű ha nincs US-ASCII-ra korlátozva a használható karakterkészlet), így a kettő közül egyértelműen ez a technikailag fejlettebb megoldás, amit véletlenül marha nehéz összehozni (szemben a case-sensivitással, ami pont ezokból bármikor fogható arra, hogy csak lusta/béna volt a nyelv/OS/stb. fejlesztője egy normális összehasonlítást megírni a legegyszerűbb bináris helyett). Ettől persze még lehet(ne) célszerűtlen, de itt már a hitviták mezejére érünk, hogy ti. ki szerint mi a logikusabb, mert mindkettő működési mód mellett hozhatók fel érvek pro és kontra is.
    Mutasd a teljes hozzászólást!
  • Szóval, az én javaslatom: XAMPP

    Próbaképpen föltettem most ezt is
    Nagyon tetszik szintén

    Lehet, hogy összeeresztem egyszer őket, mind a hármat, hogy győzzön a jobbik
    Mutasd a teljes hozzászólást!
  • A symlinkek nagyon leegyszerűsítik a fejlesztést. Például aki symfonyt használ, annak különösen nehéz lenne nélküle. Hiszen a pluginok web könyvtárai mind symlinkek. Én nem tudom hogy windows alatt hogy működik, de szerintem a symfonys task parancs nem lenne jó rá. De élesben, miután kirakod valahová, ott többnyire úgyis letiltják, tehát élesítéskor így is úgy is szívsz vele.

    A kis nagy betűs dolog tervezéssel lehet hogy kiküszöbölhető, de szerintem inkább csak odafigyeléssel. És mivel emberek vagyunk, hibázunk. De arra nem lesz idő hogy élesítéskor végignézd az összes menüpontot. Márpedig akkor érdemes olyan környezetben fejleszteni, ami a véglegesre a leginkább hasonlít.

    Egyébként én meg nem találkoztam olyan PHP fejlesztőeszközzel ami nem ment linuxon, legalább wine alatt. A photoshopot én nem veszem a PHP eszközök közé, mert az inkább design és sitebuild. Meg én nem is nyúlnék a photoshophoz. 5-10e-ért elkészítik a sitebuildet. Aki nap mint nap ezt csinálja, annak 2-3 óránál nem több, én meg - programozóként - több napon át szenvednék vele. Ráadásul a végeredmény is rosszabb az én részemről.
    Mutasd a teljes hozzászólást!
  • Hali!

    Arra akartam velük példát mutatni, hogy igenis komolyan oda kell figyelni a PHP kódokban ezen különbségekre is.


    Én csak arra lennék kíváncsi, hogy ezeket a link()... dolgokat mennyire használják "mainstream"? Több, mint két éve PHP-vel foglalkozom (masszívan, nem számítva azt a néhány hónapot, félévet, amíg "kitapasztaltam" a trükköket), de nekem még egyszer sem kellett ezeket használnom. Lehet, hogy szerencsés vagyok ezzel kapcsolatban (pedig, nem csak "sima" tartalomkezelő rendszereket készítek).

    Én Windows alatt fejlesztek, XAMPP-ot használva (tényleg nem lenne nagy dolog külön-külön, egyenként belőni a szerver "komponenseit", de minek szenvedjek vele, ha egy csomagban megkapom - ráadásul, hordozható változatban). Ugyan, használok linuxot is (mondjuk, inkább szórakozásra), de sok oka van a Windows-on történő fejlesztésnek (többnyire szubjektív - jobban tetszenek a fejlesztőeszközök -, persze olyan szoftvereket is használok, melyeknek linuxos - hasonló lehetőségekkel, kezelhetőséggel felvértezett - változata nincs, a WINE meg nem sokat ér ezeknél, ráadásul minek).
    Nekem soha nem volt még abból problémám, hogy Windows-on fejlesztek PHP-vel. Megfelelő tervezés és - főleg - "vizsgálat" kérdése (ez többnyire adott lehetőség meglétének - pl. függvények - a vizsgálata). Mindenhol, főleg, ahol felhasználótól érkezik valami, ellenőrzés, csak kisbetűs, ékezet nélküli fájlnevek (ha felhasználótól érkezik, akkor - is - konvertálás), stb.

    Szóval, az én javaslatom: XAMPP.

    Mutasd a teljes hozzászólást!
  • [OFF]
    Te ilyen nagyon linux gurunak látszol. Amúgy, ezt nem értem. Valaki használ linuxot jó, de miért kell és hangsúlyozom KELL másokra is rátukmálni? Itt most nem rád értem mert tőled nem hallom, hogy: "Bárcsak csődbe menne a microsoft és ne lenne többet windows". Mer ez lenne a PC ipar vége. Kicsit olyan a linux ezzel a sok féligmeddig használhatatlan disztribúcióval mint az avantgárd az irodalomban. A közlés minimuma és a befogadás maximuma kell hozzá. Én a magam részéről inkább használom a gépet effektíven mint szívjak vele effektíven, de nem mondom a linuxok kedvelőinek, hogy használjatok windowst.
    [/OFF]
    Valami komolyabb különbség a két php között esetleg van? Mert ez, hogy az egyik case-sensitive a másik meg nem az én értelmezésemben nem a php-k különbségeiből fakad a két rendszeren.
    Szóval ebből az én értelmezésemben kompatibilitási hiba igen lehet, amit jó tervezéssel ki lehet küszöbölni. Mindazonáltal komolyabb eltérő módon működő függvényről még nem láttam de nem is hallottam.
    Mutasd a teljes hozzászólást!
  • "Ez nem gyengeség, hanem így van tervezve."

    Igen, sokáig én is így hittem, de ma már nem vagyok ebben olyan biztos. Mert ha a kis/nagybetű érzéketlenség annyira jó, akkor miért nem alkalmazza ezt a legtöbb operációs rendszer illetve programozási nyelv? Elgondolkodtató...

    "Ez még szép, miután az UTF-8 az egy ábrázolási (karaterkódolási) forma, nem pedig locale - a két koncepció és fogalom tök független egymástól."

    Ebben igazad van, hülyeséget írtam. Csak mire ez nekem is leesett, addigra már nem engedte a Prog.Hu motorja szerkeszteni a hozzászólásom. Gondoltam is, hogy lesz majd valaki, aki beleköt.

    "Na, ez egyik nagy tévedés és lámaság ezze kapcsolatban, hogy Windows-tól elvárni a Linux-koncepciók támogatását, és ha azt nem teszi meg, akkor hiányosságként felróni."

    Részben jogos a Windows-ok alternatív op.rendszerekkel való inkompatibilitását hiányosságnak tekinteni (erre is lenne egy sor példa), de igazából nem ez volt a célom ezzel, csak legfeljebb félreérthető voltam. Arra akartam velük példát mutatni, hogy igenis komolyan oda kell figyelni a PHP kódokban ezen különbségekre is. Szóval ezúttal nem a Windows-t akartam lenézni (ami nálam ritka ), hanem a kérdést példákkal illusztrálva megválaszolni.
    Mutasd a teljes hozzászólást!
  • Szerintem a világ marhasága megkülönböztetni fájlnevekben a kis- és nagybetűket (és ugyanezt gondolom a programozás során is az azonosítók vonatkozásában

    Félig egyet értek, én camelize-decamelize függvényekkel szoktam az osztálynevek és fájlnevek között váltani... Kis és nagybetű, ékezetes karakterek ... mind zavaró lenne fájlnévben.
    Mutasd a teljes hozzászólást!
  • Azon kár vitakoznotok, hogy most melyik a jobb rendszer. Arra ott a PC fórum. Az viszont tény, hogy amint a PHP-ban elkészültem a munkámmal, nagyobb valószínűséggel fogják felteni egy linuxra mint windowsra. Sokszor még az is problémát okoz, hogy régebbi PHP van a leendő szerveren. Nyilván ASP-ben sem fejleszt senki Linuxon.
    Mutasd a teljes hozzászólást!
  • Köszi szépen!
    Mutasd a teljes hozzászólást!
  • az oroszban segithetek.
    Mutasd a teljes hozzászólást!
  • Ez pont hogy a Windows gyengesége, amiért a mai napig nem különbözteti meg a fájlnévben a kis/nagybetűket.

    Ez nem gyengeség, hanem így van tervezve. Szerintem a világ marhasága megkülönböztetni fájlnevekben a kis- és nagybetűket (és ugyanezt gondolom a programozás során is az azonosítók vonatkozásában, ezért nem is szeretem a nyelveket, amik ezt teszik). Persze elfogadom, hogy más meg másként vélekedik erről, de a lényeg, hogy ez nem "gyengeség" definíció szerint.

    A dolog ráadásul kétirányú inkompatibilitást jelent, azaz nem csak azt, hogy a Windows-on megírt kód esetleg hibásan működik Linuxon (ti. mert pl. ha nem kerül a kis-nagybetű állapot megőrzésre a fájlnévben, akkor Windows-on attól még simán jól fut a kód, de Linuxon hibásan fog működni, hiszen ott két különböző fájl próbál meg esetleg elérni), hanem fordítva is, azaz a Linuxon kifejlesztett kód hibásan működhet emiatt Windows-on (ti. mert mondjuk egy adott név kisbetűs változatában akar egy adott infót tárolni, nagybetűs változatában meg egy másikat, ami Linux alatt tényleg két fájl lesz, de Windows alatt ugyanaz az egy, így adatvesztést okozva).

    Ezekkel a különbségekkel - ami ráadásul a konkrét esetben a fájlrendszer és nem az operációs rendszer sajátossága - egyszerűen a fejlesztőnek tisztában kell lennie, és figyelnie kell rá! Meg főleg tesztelnie az összes potenciális célplatformon - azt ugyanis pont erre találták ki, hogy ti. az elméletileg jól működő dolgokról kiderüljön, hogy gyakorlatilag is jól működnek -e mindenhol ahol kell. Ilyen különbségekből egyébként is millió van más területen is - azon egyszerű oknál fogva, hogy a Windows nem Linux és a Linux sem Windows -, csak azokkal esetleg nem találkozik olyan gyakran az átlagfejlesztő, mint ezzel (mert fájlokat mindenki kezel szinte, de mondjuk távoli IPC hívásokat már nem végez, így az ottani különbségek a képességekben már nem ugranak ki annyira).

    De egy másik példa, ami Windows-on szintén problémás:
    Windows setlocale()'s implementation does not support UTF-8 encoding.

    Ez még szép, miután az UTF-8 az egy ábrázolási (karaterkódolási) forma, nem pedig locale - a két koncepció és fogalom tök független egymástól. Aki elvárná azt, hogy ez így működjön, annak gőze sincs arról, hogy mi a karakterkészlet, kódlap, ábrázolás, stb. közti különbség.

    Nem mellesleg a Windows már lassan huszadik éve támogatja a Unicode-ot, azóta, amikor még nem, hogy kéjes gondolat sem volt a PHP, de pl. a Linux azt sem tudta, hogy vannak karakterek a US-ASCII-n kívül is. Az UTF-8 kódolás pedig nem is létezett még akkor (ti. csak később találták ki/vezették be/szabványosították).

    Vagy Vista-t megelőző rendszereknél még ilyen alap dolgok se mennek Windows-on, és ezek is csak legalább 5.3-as PHP-vel, míg Linux-on ősidők óta mind használható: link(), symlink(), readlink(), linkinfo()

    Na, ez egyik nagy tévedés és lámaság ezze kapcsolatban, hogy Windows-tól elvárni a Linux-koncepciók támogatását, és ha azt nem teszi meg, akkor hiányosságként felróni. Ez ugyanolyan hülyeség, mint azt mondani, hogy azért ócska a Linux PHP-hez, mert azon futtatva nem érhetők el a PHP COM/ActiveX függvényei.

    Ettől függetlenül duplán tévedés a szóban forgó függvények esetleg részleges vagy teljes működésképtelenségét a Windows-on számonkérni, ugyanis a hardlinkeket is már NT 4.0-tól támogatja pl. az NTFS (FAT32 nyilván nem). Tehát technikailag má azóta elérhető a lehetőség; az pedig, hogy a PHP ezt (eddig) nem tudta kihasználni, az - az amúgy tapasztalataim szerint űberlamer - core PHP fejlesztőknek köszönhető, de nem a Windows hibája per se.
    Mutasd a teljes hozzászólást!
  • Microsoft Windows [verziószám: 6.1.7600]
    Copyright (c) 2009 Microsoft Corporation. Minden jog fenntartva.

    C:\WebServers>ping localhost

    Pali-PC [::1] pingelése - 32 bájtnyi adattal:
    Válasz ::1: idő<10 ezredmp.
    Válasz ::1: idő<10 ezredmp.
    Válasz ::1: idő<10 ezredmp.
    Válasz ::1: idő<10 ezredmp.

    ::1 ping-statisztikája:
    Csomagok: küldött = 4, fogadott = 4, elveszett = 0
    (0% veszteség),
    Oda-vissza út ideje közelítőlegesen, milliszekundumban:
    minimum = 0ms, maximum = 0ms, átlag = 0ms

    C:\WebServers>

    Nincs ezzel semmi gond, csak a dbHost beállításnál, az adatbázis eléréshez kell a trükközés. Lehetett volna a "hosts" fájlban a kikommentezés, de egyszerűen nem bírtam a w7 védelmével (nem tudtam felülírni), hiába kezdő programozó:)

    Na föltelepítettem a Denwer-t. Az első benyomásom nagyon jó, már csak azért is, mert olyan szolgáltatásai is vannak, amikről nekem eddig fogalmam sem volt. Lesz most már subdomain -em, meg ssl -em, meg egy jó pár dologról fogalmam sincs, hogy mi is az. Mindenesetre, lesz mit tanulnom (meg oroszul is fel kell szívnom magam)
    Mutasd a teljes hozzászólást!
  • És ha megpingeled a localhostot, mit ad vissza?

    Mutasd a teljes hozzászólást!
  • Mostanában váltottam w7-re. A korábban megszokott EasyPHP-t tettem föl, és vannak is gondjaim. Pl. a "localhost"-ot a dbHostName esetében a 127-es kezdetű IP-re kellett cserélnem, meg a RewriteUrl szintén nem megy.
    Várom most a Denwer letöltő URL-jét. Kíváncsi vagyok rá...
    Mutasd a teljes hozzászólást!
  • Hát van pár, mondjuk egy részüket wine-vel lehet futtatni, legalábbis azt olvastam... Most úgy néz ki a dolog, hogy vmware-el felteszek egy linuxot, és arra teszek egy cherokee szervert, később meg majd csinálok egy szervergépet ilyen célra.

    Nem is ez az összeomlás zavar a windows-os szerverben, egyszerűen úgy érzem, hogy váltani kell valami komolyabb tesztelési környezetre.
    Mutasd a teljes hozzászólást!
  • Ez pont hogy a Windows gyengesége, amiért a mai napig nem különbözteti meg a fájlnévben a kis/nagybetűket.

    De egy másik példa, ami Windows-on szintén problémás:
    Windows setlocale()'s implementation does not support UTF-8 encoding.

    Vagy Vista-t megelőző rendszereknél még ilyen alap dolgok se mennek Windows-on, és ezek is csak legalább 5.3-as PHP-vel, míg Linux-on ősidők óta mind használható:
    link(), symlink(), readlink(), linkinfo()

    Én egyébként is még desktop és devel-time is Linux-ot (Ubuntu-t) használok, és mivel a PHP-t futtató szerverek legynagyobb részén úgyis Linux megy, így eszem ágában se lenne Windows-on tesztelési céllal webszervert futtatni.

    nova76: Nekem már két olyan munkahelyem is volt, ahol pontosan ugyan ezt a megoldást alkalmaztuk. A tesztszerveren Linux, a fejlesztő gépeken meg szabadon választott. Ez utóbbira volt egy-két ember, aki Windows-t használt, és voltak (velem együtt), akik Linux-ot sőt, a designer-ünk MacOsX-et tolta.
    Mutasd a teljes hozzászólást!
  • Itt egy hiba, ami működik Win alatt, de hibára fut(hat) linux alatt:
    $r = fopen("Valami.TXT", "r")
    Mutasd a teljes hozzászólást!
  • Ki szokták írni a php.net-en. Én már nem emlékszem mi volt, de talán még itt is belefutottam már ilyen kérdésbe. Persze aki tud olvasni az könnyen skippeli ezeket az objektumokat/függvényeket. De nekem fura is lenne ha nem lenne ilyen, hiszen némely függvény eléggé rendszerközeli dolgokat is művel. Én olyan csúnyán megjártam egyszer, hogy létrehoztam egy függvényt, ami aztán volt linuxon és ott kénytelen voltam átnevezni a sajátom (és ahol használtam, mindenütt). De már vagy 2 éve, és nem emlékszem mi volt. De mint írtam, a DS is mindig el van írva. Én is sokat dolgoztam windowson, de már nem tenném.

    A virtual box fut windowson is.
    Egyébként mely programok nincsenek linuxon? Én még puttyot is használok Total commander, notepad++ is van, ha kell. Ok, a metin2 nem fut, ezért van nekem is itthon windows
    Mutasd a teljes hozzászólást!
  • Hmm ezt jó tudni, eddig még nem volt olyan gondom, hogy a szerver nem ismerte valamelyik függvényt. Nincs valami lista arról, hogy mi nem ajánlott?

    Linux-al nincs bajom, csak van néhány program, amiket már megszoktam az évek alatt, és nincsenek linux-ra, aztán ezért nem váltok.
    Mutasd a teljes hozzászólást!
  • Mndjál már nekem egy példát légyszives ami a windowsos PHP-n fut de a Linuxoson hibát dob vagy fordítva . Szórakoztam egy 3-4évig PHP-val WINDOWS-on és sosem volt bajom azzal, ha később linuxon kellett futtatni. Szóval engem érdekelne, hogy te milyen függvényekről tudsz amik nem jók .

    Mindazonáltal:
    énis WAMP-ot használtam de nem találköztam a leírt hibával. De van még XAMP-is . De ha tutira akarsz menni akkor telepítsd magadnak: Apache - PHP - MySQL - és ami még kell. Nem olyan nehéz külön felpakolni és beállítgatni őket.
    Mutasd a teljes hozzászólást!
  • Nálunk a cégnek van egy saját fejlesztői szervere (ubuntu) és azon dolgozunk. Mindenki olyan gépet/oprendszert használ amit akar, de a fejlesztést a szerveren végezzük.
    Ez nekem annyira bejött, hogy ha netalántán otthon dolgoznék és nem lenne módom a szerveren végezni a munkám, akkor felraknék egy virtualboxot és azon nyomulnék. Akármit csinálsz a windowsos PHP nem olyan mint a linuxos. Egy csomó függvény is hiányzik belőle, illetve egy csomó olyan van benne, ami esetleg ott nincs is. Így amikor kirakod a programod, akkor jössz rá, hogy nem megy, vagy nem azt csinálja. Vagy épp nem figyeltél oda, és valahol valami útvonalat elgépeltél, stb. Egyébként sem baj, ha megismerkedsz a linux lelki világával, egy idő után meg lehet szeretni.
    Egyébként ha vállalkozó lennék akkor is lenne egy bérelt szerverem, vagy VPS-em. Azok ott backupolnak, vigyáznak a dolgaimra és nem is drágák (3-4e/hó).
    Mutasd a teljes hozzászólást!
  • Ha elboldogulsz az orosszal próbáld ki: DENWER
    Mutasd a teljes hozzászólást!
  • Közben kiderült, hogy a php5ts.dll irtja le a rendszert, amit furcsállok, mert december óta van fent ez a rendszer, és csak májusban jelentkezett a probléma. Még mindig xp frissítőcsomagra gyanakszom.

    szerk:
    Azt írják, hogy a php5apache2.dll-t frissíteni kell php5apache2_2.dll-re, és az majd megoldja. Hát nálam az az alapbeállítás, szóval nem oldja meg...

    elnézésüket kérjük, blabla...
    szAppName : httpd.exe
    szAppVer : 2.2.11.0
    szModName : php5ts.dll
    szModVer : 5.3.0.0
    offset : 00023d9a
    Mutasd a teljes hozzászólást!
  • Üdv.

    Van egy wampserver-em feltéve, és elég furcsán viselkedik, a hibás php kódok futásakor fogja magát, és kidobja, hogy ismeretlen hibát észlelt, tájékoztassam a microsoftot, szóval a szokásos szarságokat. Újratettem az egészet, de a probléma nem múlt el. (Lehet, hogy valamelyik xp service pack, ami felelős a történtekért, majd utána nézek.)

    Mindenesetre kíváncsi vagyok, hogy ti mit használtok, hátha érdemes lenne váltanom wampserver-ről valami másra.
    Mutasd a teljes hozzászólást!
abcd