Megjelent a PHP 5.4
A PHP 5.4 verziójának kiadásával izgalmas (és régóta hiányzó) dolgok jelentek meg a nyelvben, melyek nagy részét szívesen fogom szinte minden nap használni (majd ha élesben tényleg át lehet állni rá). Sok olyan dolog is ki lett végre kukázva, melyek már teljesen elavult nyelvi elemnek számítottak. Megpróbáltam összegyűjteni azokat a lényegesebb változásokat, melyek a leginkább tetszenek.
Beépített webszerver
Éles környezetben nem ajánlott a futtatása, de ezentúl egy webszerver is be van építve a PHP-be. Így indítható:
php -S localhost:8000Ebben az esetben az adott könyvtár lesz a weboldal gyökere, onnan alapból az index.php vagy index.html fájlok kerülnek kiszolgálásra. Paraméterként megadható egy PHP fájl neve is, ami „router”-ként fog működni. Bővebben: Features: command line webserver.
Könnyítések
Ide azokat az újdonságokat soroltam, melyek nélkül lehet élni, de átláthatóbb, tömörebb, „szebb” kódot eredményez a használatuk (a tömör alatt itt nem a Perl-féle 8 byte-ba minden algoritmus belefér szintakszisra gondolok).
A JavaScriptben megszokott tömör tömb deklarációt a PHP-ben sem kell már nélkülöznünk. Ezentúl elhagyhatjuk az array() kulcsszót, és helyette szögletes zárójelet használhatunk. A JavaScripthez képest eltérés, hogy az asszociatív tömböknél is szögletes zárójelet kell használni (bár ebben semmi meglepő nincs):
$a = [1, 2, 3];
$b = ['foo' => 'orange', 'bar' => 'apple', 'baz' => 'lemon'];A PHP-ből már nagyon hiányoltam, azt az – általam – régebben a Perlben, manapság a JavaScriptben gyakran használt nyelvi lehetőséget (de a Java, Ruby és minden más modernebb nyelv is ismeri), mely lehetővé teszi, hogy egy frissen példányosított osztálynak egyből meghívjuk egy metódusát:
$myCar = (new Car)->setSpeed(100)->setColor('blue');JavaScriptben, jQuery-ben sok ilyet láthatott már mindenki. Ha a metódusok visszatérési értéke minden esetben a példányra mutat (return $this), akkor válik lehetővé ennek a megoldásnak a hatékony használata.
Nagyon hasonlít erre az az eset, amikor egy függvény tömb értékkel tér vissza, és ennek a tömbnek egyből egy elemére szeretnénk hivatkozni. Ezentúl ez is lehetséges:
function fruit ()
{
return array('a' => 'apple', 'b' => 'banana');
}
echo fruit()['a'];Szintén könnyítés, és igazából nem is értem, hogy eddig miért nem volt rá lehetőség, hogy a bináris számokat ezentúl tömören le tudjuk írni:
$x = 0b001110;Trait
A trait-ek (magyarul jellemző, jellemvonás) szimplán összegyűjtött metódusok, melyeket egy osztály deklarációjakor használhatunk. A több helyen felhasználható, ismétlődő kódrészleteket lehet így egy helyre kigyűjteni, egyik példa lehet a Singleton design pattern megvalósítása:
trait Singleton
{
public static function getInstance()
{
…
}
}
class A
{
use Singleton;
…
}
class B extends ArrayObject
{
use Singleton;
…
}
A::getInstance();
B::getInstance();Típus kényszerítés függvény paraméterekre
A PHP 5, illetve 5.1 óta egy függvénynél kötelezővé tehetjük, hogy az egyes paraméterek egy adott osztályba tartozzanak, vagy pedig szigorúan tömbök legyenek. Az 5.4-ben lehetőség van a függvény típus jelölésére is a callable kulcsszóval:
function foo(callable $cb)
{
$cb();
}Teljesítmény
Vannak a PHP-nek olyan részei, melyek használatát illik mellőzni (nem csak teljesítmény okokból), ennek ellenére elég sok olyan kód fellelhető szerte a világban, melyek nem így tesznek. A PHP 5.4-ben pár ilyen megoldásnak is javult a teljesítménye.
A $GLOBALS tömb inicializációja egy erőforrásigényes művelet, mind a sebesség, mind a memóriahasználat szempontjából. A PHP 5.4-ben a tömb csak első használatkor inicializálódik ezentúl.
A @ operátor (ejtsd: SILENCE!) ezentúl egy kicsit gyorsabb lesz.
Elfelejthetjük!
Eltávolításra került a PHP-ből a safe mode, továbbá a y2k_compliance, a magic_quotes_gpc, a magic_quotes_runtime, a magic_quotes_sybase, a register_globals, a register_long_arrays, az allow_call_time_pass_reference kapcsolók!
Továbbiak
Általában véve (a marketingszöveg alapján) a PHP 5.4 teljesítménye érezhetően gyorsabb, kisebb a memóriafoglalása és 100 feletti hibát javít. A teljes lista elérhető itt: http://php.net/ChangeLog-5.php#5.4.0
■
Teljesítmény
A Zend más kiterjesztéseknél is okozhat gondot, jellemzően azoknál, amelyek fejlesztése szünetel, például a memcached sem fordul le (a memcache viszont igen).
az apc-ben meg vannak ismert
Tyrael
Tudsz ajánlani alternatívát?
szerintem egyszerubb
http://bit.ly/z5iqWH
szerintem meg igy is az apc all a legkozelebb a mukodeshez (xcache, eAccelerator le sem fordul, raadasul egyik sincs a php esernyoje alatt, ergo nem akarjak/tudjak a core fejlesztok direktben javitani a hibat az adott extensionben.
A Zend Server/Optimizer az ami szerintem meg belathato idon belul tamogatni fogja az 5.4-et.
ps: ha megis belefognal az eAccelerator peccselesebe, akkor megprobalkozhatsz az ottani levelezolistaval, ha ott nem kapsz segitseget, akkor erdemes lehet meg irc-n megkerdezni (efnet #php.pecl) hatha valaki nagyon raer es tud segiteni.
Tyrael
zend optimizer
Köszi az összefoglalót
A könnyítések bekezdésben leírt pontokat én is nagyon hiányoltam, főleg a method chaininget és a függvényhívásnál visszakapott tömb elemeire való közvetlen hivatkozást.
Sajnos az még nagyon távoli, hogy az éles rendszerekkel is átálljunk 5.4-re.
Köszi az összefoglalót, nem
http://blog.kodfejtok.hu/php-5-4-izelito
akkor mar en is belinkelem a
http://webkonf.org/2011/eloadasok.html#php5.4
Tyrael
Ez jó, köszi! Jó anyag. Főleg
hehe
Amit én hiányolok, hogy a
Amit szintén hiányolok, hogy string, integer, stb típusokat nem lehet ellenőriztetni (bár ezt már lehet, hogy javították, nem követem az új verziókat).
Ami szintén jó lenne, ha a példányváltozó deklarálásánál meg lehetne adni a típusát és az értékadásnál ellenőrizné a php, hogy tényleg abba a típusba tartozik e, illetve ez az automatikus kiegészítésnél is nagy segítség lenne, mert pl netbeans-nél ha most setter-rel állítasz be valamit, akkor annak elfelejti a típusát, és nem ajánl fel semmit.
Ha ezeket sikerülne megvalósítani, akkor sokkal élvezhetőbb nyelv lenne.
SplTypes
Vagy a Javára :)
vagy C#-ra :)
Attól, hogy belekerülne
(Amiket felsoroltam szerintem pillanatok alatt bele lehetne tákolni a mostani PHP-ba.)
a levlistan ki lett fejtve
pl. behuzol egy ZF vagy PEAR libet, ha valahol hasznal scalar typehintet, akkor onnantol kezdve te is elkezded ugyanazt a tipushintelest alkalmazni, hogy mar te sem kaphass rossz tipust, ezaltal megakadalyozando hogy rossz tipust adj a lib fuggvenynek, vagy irsz egy csomo boilerplate kodot, ahol a string 1-bol int 1-et csinalsz, csak hogy nehogy hanyat dobja magat a libben levo fuggveny.
mindket esetben befolyasolta a hivo kornyezetet(egeszen a hivasi graf tetejeig) a teny, hogy valahogy egy eldugott helyen typehintet hasznalt valaki.
az hogy az osztalyok/tombok kapcsan ez a szigoru tipusossag a typehint kapcsan nem okozott mar eddig is nagyobb fejfajast, csak annak koszonheto, hogy az atlag fejleszto nem teved akkorat, hogy rossz tipusu objectet at, vagy ha igen, akkor meg orul is neki, hogy felrobbant a kod, mert nem lehet mast tenni abban a helyzetben.
ha viszont ugyanez a hiba valtodna ki, mert valahol "1" ment at 1 helyett, az elegge kicsapna a biztositekot egy csomo embernel, mert egyszeruen nem ehhez vannak szokva, nem igy mukodik ez a nyelv.
Tyrael
ha viszont ugyanez a hiba
Lehet, hogy kivétel vagyok, de nehezen tudom elképzelni azt, hogy "1" megy át valahol 1 helyett. Az űrlapokban stringként megy át minden, ott egyértelmű, hogy azt kapok, adatbázisban szintén, a SOAP-ban lehet típust konvertálni, szóval ott a wsdl-ben megadott típus fog átmenni, az összes többi esetben meg látod a kódot, amiből az érték jön, de a biztonság kedvéért le lehet ellenőrizni mondjuk is_int-el, vagy konvertálni...
Én nem vagyok ellene a típusosságnak, szóval engem ez egyáltalán nem zavarna, persze el tudom képzelni, hogy sokakat igen.
"Lehet, hogy kivétel vagyok,
ahogy te is leirtad, az esetek nagy reszeben az adatok amikkel dolgozik a scripted string tipusuak lesznek, fuggetlenul attol, hogy szamokat tartalmaznak.
ha bevezeted a szigoru tipusossagot a php-be(ezaltal megszunteted a type jugglingot), onnantol kezdve minden ilyen esetben allandoan inicializalas elott explicit kellene castolgatnod a valtozoidat, vagy kapnad a warning/recoverable errorokat a type mismatchre.
"Én nem vagyok ellene a típusosságnak, szóval engem ez egyáltalán nem zavarna, persze el tudom képzelni, hogy sokakat igen."
en pedig hetero vagyok, de ezert nem kampanyolnek a buzibar profilvaltasa ugyeben.
mindenki hasznalja a sajat izlesenek megfelelo nyelvet, es ne akarja raeroltetni masokra a sajat preferenciait, kulonosen akkor ne, hogyha ezzel a velemenyevel az adott kozossegben egy nagyon apro kissebbseget kepvisel.
Tyrael
+1
Ja, és szerintem (is) jól áll a PHP-nek, hogy nem típusos
Haha, én is hetero vagyok,
"Amit én hiányolok, hogy a
miert lenne ez jo? azon kivul, hogy eltorne egy csomo kodot? melyik masik nyelvben lattal erre peldat?
"Amit szintén hiányolok, hogy string, integer, stb típusokat nem lehet ellenőriztetni "
miert ne lehetne? is_int, is_string, etc.
vagy type hintingre gondolsz? aktiv (ertsz tobbszaz emailt generalo) vita zajlik most is (mar sokadszor) az internals levlistan, az az erzesem, hogy be fog kerulni a scalar typehint a nyelvben, viszont nem a jelenlegi class/array mintajara strong typinggal, hanem a scalarokra php-ban jellemzo weak typinggal (azaz ha int/bool/string-re fogsz hintelni, akkor eltero tipus eseten nem recoverable errort fog dobni a php, hanem megprobalja castolni a valtozot a jelenlegi type juggling szabalyai szerint).
"(bár ezt már lehet, hogy javították, nem követem az új verziókat)."
hat oo ize, akkor talan nem kellene ilyen kategorikus kijelenteseket tenni.
"Ami szintén jó lenne, ha a példányváltozó deklarálásánál meg lehetne adni a típusát és az értékadásnál ellenőrizné a php, hogy tényleg abba a típusba tartozik e"
bar paran agalnak ellene, de a core fejlesztok reakciobol biztosra veheto, hogy szigoru/eros tipusossag sosem fog bekerulni a nyelvbe.
ha erdekel hogy miert, akkor lasd levlista.
ha megis szukseged van ra, akkor van egy csomo szigorubban tipusos nyelv, mint a php.
"illetve ez az automatikus kiegészítésnél is nagy segítség lenne, mert pl netbeans-nél ha most setter-rel állítasz be valamit, akkor annak elfelejti a típusát, és nem ajánl fel semmit."
ez mitol oldodna meg? a netbeans tovabbra sem fogja erteni, hogy mit csinal a settered, illetve lehet olyan logika a setteredben, hogy parametertol fuggoen mas-mas valtozoba teszi a bealitani kivant valtozot, innentol kezdve megint nem tudhatja a netbeans, hogy milyen tipust engedhetsz.
viszont a setterben megadott typehint (vagy docblock, ami mar jelenleg is tamogatott a scalar tipusokra is) elegendo informaciot hordoz ahhoz, hogy az okos IDE fel tudja ajanlani a kiegeszitest.
"Ha ezeket sikerülne megvalósítani, akkor sokkal élvezhetőbb nyelv lenne."
nem, akkor egy maszlag lenne, persze ez csak az en velemenyem.
csodalkozom, hogy a thread kezelest nem hoztad fel, vagy hogy alakitsunk minden errort/warningot/notice-t exceptionne, es hogy kukazzuk le a @ operatort.
Tyrael
ne adj
Ne adj ötleteket! :D
"Amit én hiányolok, hogy a
miert lenne ez jo? azon kivul, hogy eltorne egy csomo kodot? melyik masik nyelvben lattal erre peldat?
Azt hiszem az 5-ös verzióban változtatták meg a PHP-t olyanra, hogy az összes objektumot alapértelmezetten referenciaként adja át, ne pedig másolja őket. Sajnos a tömböket kihagyták, ezért azok még mindig másolódnak alapértelmezetten, aminek meg nincs túl sok értelme az esetek döntő többségében... (Ha objektumba zárod a tömbödet, akkor viszont megoldódik ez a probléma.)
A másik gond a tömb referenciakénti átadásával, hogyha értéket adunk át, akkor elszáll hibával:
Szerintem ezt erősen félreértetted...
Imho a PHP már most egy nagy maszlag, a fejlesztői meg szerintem maguk sem tudják, hogy mit akarnak. Dönthettek, hogy bevezetik a típusellenőrzést vagy sem, nem tudták eldönteni, így született a mostani köztes megoldás, ami minden, csak nem jó. Ez olyan, hogy vagy megcsinálom rendesen, vagy sehogy... (Egyébként ez a káosz érződik az egész nyelvben, nem csak a típusellenőrzésnél, de ez az én véleményem...)
Thread-re nincs szükség a PHP-ban, ha csak weblap generálásra használod, amire a nyelv amúgy hivatott... Miért is kéne mindent exception-re alakítani?
Azt hiszem az 5-ös verzióban
kicsit ennel osszetettebb volt a valtozas, de felhasznaloi szempontbol valoban ez az egyik lathato kovetkezmenye.
azzal ugye tisztaban vagy(szerintem irtam mar itt neked weblaboron regebben), hogy a php a copy-on-write modellt alkalmazza, innentol kezdve a referenciakkal valo jatszadozassal nem igazan lehet memoriat sporolni az esetek 99%-ban.
ha erdekel ez mukodes kozben, akkor itt egy pelda:
http://codepad.viper-7.com/8OGxgq
ahogy latod a tomb masolasa minimalis plusz memoriafoglalassal jar, egeszen addig, amig nem modositok a tombon, mert fizikailag akkor kell csak masolnia, addig ugyanarra a memoriateruletre mutat a masolat tomb is.
ez by design ilyen, erteket nem adhatsz at referenciakent, mivel a hivo kornyezetben az array()-t nem a rendeled hozza semilyen valtozohoz, ezert nem lesz mire hivatkoznod a referenciakent.
az $appender->append($foo=array()); nyilvan mukodne.
de meg mindig kivancsi lennek, hogy a peldadban miert erne meg referenciakent atadni a temp tombot, az a gyanum, hogy csak memoriat szeretnel vele sporolni (a referenciakenti atadas masik elonyet az jelentene, hogy az igy atadott parametert a meghivott kod modositani tudna, de te pont azt szeretned, hogy a hivo kornyezetben ne kelljen valtozot letrehoznod, ezt ebben a formaban nem tudnad kihasznalni), ami amint mar emlitettem felesleges, hiszen a COW miatt nem sporolsz semmit.
ebben a peldadban nincs setter, az eredeti postodban arrol beszeltel:
en erre probaltam valaszolni.
a mostani peldadnal maradva: nekem (a void, illetve MyTest typehint nelkul) ez szepen mukodik PHPStorm-ban, siman felajanlja a helloWorld metodust (gondolom a __construct-ban szereplo ertekadas miatt)
ha kiszedem a constructort, akkor a kovetkezo docblock szinten mukodik nalam:
/**
* @property MyTest $test
*/
tovabbi infoert katt ide (ez nyilvan setterre is mukodik szepen).
az evek soran volt 1-2 paradigm valtas/eltolodas, de nem mondanam hogy nem tudjak hogy mit akarnak.
amit en latok, az az, hogy van egy marhanagy teher rajtuk, hogy egyreszrol a felhasznalok legnagyobb tobbsege azt szeretne, hogy semmilyen visszafele nem kompatibilis valtozas ne tortenjen, emellett van egy nagyon hangos tomeg, akik viszont azt szeretne, hogy legyen toronyora lanccal, jellemzoen valamilyen mas "trendibb" programozasi nyelv felol erkeuve.
ekozben egy nagyon pici aktiv fejlesztoi mag viszi a projectet, akik tobbnyire konzervativok a valtozassal szemben, es gyakorlatilag a core fejleszto es az atlag php fejleszto szinte semmilyen forumon nem talalkozik egymassal, ezert a kozvetlenul csak a framework fejlesztok, meg az ifju lelkes java titanok iranyabol erkezik feedback.
utolag visszatekintve nem biztos, hogy a legjobb megoldas volt a jelenlegi typehintek bevezetese, de szerintem nem annyira veszes.
ha belegondolsz a php sosem tamogatta az objectek kozotti type juggling-ot, ezert onmagaban az nem lenne problemas(bar az array typehintnel mar inog egy picit a lec).
egyetertek, szerintem is az a nagyobb problema, hogy ezzel a felmegoldassal kinyitottak pandora szelencejet, mivel azotta folyamatosan felmerulo igeny, hogy de a scalar tipusokra miert nem tamogatott.
utolag en azt gondolom, hogy az lett volna a jo megoldas, hogy csak akkor kerulhet be a nyelvbe a typehint, hogy ha mar ki van dolgozva a koncepcio az osszes tipusra.
igen, nekem is sokszor az a velemenyem, hogy a kevesebb munkaval jaro megoldast kerul megoldasra, ami legtobbszor nem a legjobb, vagy tuneti kezeles.
ez volt a namespace-ek kapcsan (egyreszt ugye ezert lett a \ a separator, mert egyebkent a buta parser nem tudta volna feloldani a ketertelmuseget, illetve ezert lettek a namespace-ek a jelenlegi formajukban implementalva, aminek a kovetkezmenye az, hogy nem tudsz egy nevterbol mindent exportalni, mert igazabol a nevter nem is egy plusz absztrakcios szintkent van a core-ban implementalva, csak elso ranezesre tunik ugy.
ezek meg a gyakori "hyped" otletek/igenyek a mas nyelvekbol erkezo fejlesztok iranyabol.
itt lehet csemegezni a jobbnal jobb otletek kozul, es ezt az emberek komolyan is gondoljak (najo, kiveve talan Chuck Norrist).
ps: pont most olvasok egy slide-ot, ahol Johannes (az 5.3 kiadasmenedzsere) egesz jol elmagyarazza hogy miert nem erdemes eroltetni a referenciak hasznalatat:
Tyrael
innentol kezdve a
Nekem volt olyan eset, amikor a referenciakénti átadással (lehet, hogy memóriát nem), de sebességet sikerült növelnem. Már nem emlékszem pontosan a kódra, csak arra, hogy egy nagyon nagy stringet adtam át benne referenciaként. Mondjuk szerencsésebb, ha egy példányváltozóba rakod bele az adott stringet, és úgy tud utazni a metódusok között, ilyen átadások nélkül. Mai fejjel már biztosan így oldanám meg. A tömböknél csak arra akartam utalni, hogy nekem sok esetben az eredeti tömb módosítására lenne szükségem, amit meg nem lehet úgy megoldani, ha csak egy másolatot kapok. Persze sok esetben meg a másolat is elég, ha mondjuk adatbázis sorokat dolgozol fel...
Persze, csak előbb törném el a kezeimet, mint hogy ilyet leírjak...
/**
* @property MyTest $test
*/
Na én is valami ilyesmire gondoltam, nem tudom, hogy netbeans-ben van e lehetőség rá...
Én ezt a hozzáállást nehezen tudom megérteni. Ha vannak unit test-jeid egy rendszerhez, akkor pillanatok alatt kidobják, hogy mi az, ami az új PHP verzióval nem megy, és tudod javítani. (Gondolom az említett fejlesztőknek nincsenek unit testjeik.) A másik meg, hogy ha nem kompatibilis a kódjuk az újabb verzióval, akkor ne váltsanak át rá. Sok szolgáltatónál már most is lehet php verziót választani, egyáltalán nem kötelező váltani... (Legalábbis azonnal biztosan nem.)
Pontosan az array, ami kiverte nálam a biztosítékot, mert ha azt mondják, hogy csak az objektumokra működik a type hint, akkor azt elfogadom, de akkor minek vették bele az array-t? És ha már az array-t bevették, akkor a többi típust miért nem? Szerintem sokkal jobban át kellene gondolniuk minden ilyen lépést mielőtt bevezetnék.
A lényeg itt csak annyi volt,
Lehet van másik szerkesztő, ami alkalmasabb erre, mint a NetBeans. Eleve a PHP IDE-ből van legalább egy fél tucat használható, talán érdemes lenne velük kísérletezni. Lehet valamelyik tudja azt a szolgáltatást, amire neked szükséged van. Vagy ha nem, akkor is írhatsz a NetBeans alá egy kiegészítőt, ami megvalósítja ezt neked.
Egyelőre nem volt időm
probald mar ki pls. lusta
szerk: targytalan, latom lejebb, hogy sikerult megoldani.
Tyrael
Közben utánanéztem,
(Majd utánanézek annak is, hogy a visszatérő értékekkel mit lehet kezdeni...)
annotációk
a netbeans a következőket is kezeli:
@return <típus>
@param <típus> $paraméternév (így a metóduson belül lesz a paraméterre autocompletion)
ill. osztályokat még a következőkkel lehet annotálni:
@method <metódusnév> (ha __call() -lal implementálod)
@property <attribútumnév> (ha __get() __set() -tel implementálod)
@property-read <attribútumnév> (ha csak __get() van)
A /** -nél a két csillag azért kell, mert a javadoc is így működik, és ezért ez láthatóan konvenció lett.
Én ezt találtam a témában, a
nem biztos h olyan konnyu tesztekkel
Meg ha vannak is tesztek a rendszerre, egy 10 eve fejlesztett es nap mint nap hasznalt programot nem kis effort atrakni egy visszafele nem kompatibilis frissitesnel...talan ez egy nagy erv lehet hogy agalnak ellene
Meg ha vannak is tesztek a
Senki sem mondta, hogy kötelező frissíteni...
Van, amikor nincs más
Értem.
ez igy van
Persze, de az új verziók sem
Ez sosem szabad, hogy
ez by design ilyen, erteket
az $appender->append($foo=array()); nyilvan mukodne.
Csak nem úgy, ahogy várod.
Nyilván ha csak dísznek kell az értékadás, hogy tudj tömbliterált tenni a függvényhívásba, akkor mindegy, de egyébként szépen példázza, mekkora katyvasz a referencia szerinti értékadás, teljesen ötletszerű, hogy mit tekint hibának és mit nem.
igen, a valaszodbol rajottem,
($i=1 muvelet 1-gyel fog visszaterni (ezt adjuk at referenciakent), "mellekesen" pedig beallitja $i erteket 1-re.)
Tyrael
Igen, de ez teljesen
Á ugyan, jó ez :D Nálam is
Nálam is megkapta az arany málnát, nem túl sűrűn használom...
Azért jó...
1. ő az úr a házban (legalábbis az egyik, ha többen állnak össze)
2. iszonyat gyors külföldre is
3. kb ugyanannyiba kerül mint egy magyar hosting, ahol folyton reklamálni kell minden feature-ért, itt viszont nem. A legkisebb csomag bőven elég két embernek, így fejenként csak 10 dodó egy évre. De ha fusi melókat tudsz/akarsz hostolni (20GB azért elég nagy hely), akkor még pénzt is tudsz keresni vele.
4. nem kell a fizikai vassal foglalkozni, fejleszteni, vinyót cserélni, ügyeletet tartani.
5. ha 3-4 innovatív hangulatú fejlesztő összeáll, akkor nem csak hogy még olcsóbb is lesz, hanem mindig mindenből fel lehet rakni a legfrissebb verziót is.
Én a Linode-nál vagyok közösen egy haverral. Ha ő is belemegy (mert miért ne), akkor felrakjuk az Apache 2.4-et és a PHP 5.4-et, mihelyst az Ubuntuba belekerülnek csomagként.
Aztán már csak a Zend Framework 2-nek kell végre célba érnie :)
@linode
http://bitcoinmedia.com/compromised-linode-coins-stolen-from-slush-faucet-and-others/
[/off]
ez mi?
Milyen poolnak a bitcoin balansza alacsony? És ez mit jelent? Lehet, hogy én csinálok valamit rosszul, de ez nekem nem mond semmit...
bitcoin megvan? ha nem, akkor
ha nem, akkor lasd wikipedia
roviden: futtatsz egy progit, general szepen lassan egy virtualis valutat, amire van egy elosztott rendszer hogy anonym modon tudj penzt mozgatni.
ezt a virtualis valutat tobbfele modon penze tudod tenni, a forgalomban levo mennyiseg alapjan alakul az arfolyam.
a blogpost iroja egy olyan clusternek/poolnak az uzemeltetoje, ahova mas "banyaszok" is be tudnak tarsulni.
a hir arrol szol, hogy tegnap tobb ilyen bitcoin banyat is feltortek, es atutaltak az ott levo mozdithato vagyont, es a nyomok alapjan nem a vps-t tortek fel, vagy a rajta futtatott szoftverek valamelyiket, hanem a tamadok a linode admin paneljen keresztul leptek be, modositottak root jelszot, leptek be a szerverre, es utaltak el a penzt.
ugyan a tamadas csak egy celzott kis csoportot erintett (ahol az eddigi hirek alapjan a poolok uzemeltetoje mindenhol benyelte az okozott veszteseget, es nem terhelte at ezt a tagokra), de amennyiben bebizonyosodik, hogy a linode adminja a lyukas, az elegge kellemetlenul erinthet minden linode felhasznalot.
roviden kb. ennyi a hir ide vonatkozo resze.
Tyrael
+1 a linodera (bar a mai
dotdeb repobol mar most is felrakhatod az 5.4-et, de ahogy irtam mar, en meg varnek vele kicsit (legalabb amig az apc-s crash problemakat javitjak)
Tyrael
Speed test