Posts by K.Rens

Google heeft afgelopen nacht Panda Update 3.9 uitgerold.
Bij deze update zou je voor het eerst sinds lang weer wijzigingen kunnen merken in de resultaten die je krijgt.
Ongeveer 1% van de resultaten wordt beïnvloed door deze wijziging.
Wat er exact werd gewijzigd weten we nooit, maar in het algemeen hebben de Panda updates altijd tot doel om sites met weinig informatie of een lage kwaliteit slechter te laten scoren.
Het zijn vele kleine updates die telkens vechten tegen link- & contentfarms.

Het enige dat ikzelf tot nu toe merk, is dat google steeds minder in staat is om mij snel naar goede sites te sturen.

Als ik bv zoek op 'criminalspoint', krijg ik nog altijd veel rommel te zien in google...
https://www.google.be/webhp?so….,cf.osb&biw=1846&bih=995

In dit geval zou dit niets hebben uitgemaakt.
Een heel serverrack lag eruit, zelfs op een andere server zou de site down zijn geweest.

Het probleem kwam door een verhuis in het servercentrum, waarbij de machines niet correct waren aangesloten.
Ik zat op dat moment net in Tunesië, had geen internet verbinding en zelden telefoonverbinding.
Heb na enkele uren meteen gevraagd aan mijn CP team om het servercentrum te contacteren met de vraag het op te lossen.
Ze konden dit immers beter opvolgen dan mij.

PHP.net heeft op 19 juli een nieuwe versie, PHP 5.4.5, gelanceerd.
Deze versie bevat meer dan 35 verbeteringen, waaronder voor de functies json_encode en serialize.
Een volledig overzicht van de wijzigingen kun je bekijken op PHP.net.

Zoals gewoonlijk, adviseren we om te updaten naar deze laatste versie.

Beste leden,

Onze servers worden morgen verhuisd naar een ander rack.

Onze ISP belt me als hij zo ver is.
Meteen daarna worden de VM's op alle servers suspended.
De verhuis duurt ongeveer een kwartiertje (+eventueele routing problemen).

We weten nog niet presies hoe laat het zal gebeuren, maar hopelijk merken jullie er niet te veel van.

Bedankt voor je begrip,
Koen en je CP-team

Bedankt!
Goede tip.
Nemen we zeker mee voor de bespreking in onze volgende teammeeting.

Beste leden,

Zoals beloofd:
hierbij de tweede sneak-a-peak van een nieuw CriminalsPoint project.

Dit keer voor het eerst met grafisch materiaal:

Hierboven kunnen jullie een deel zien waarop we verder bouwen.
In de finale versie wordt disclaimer mogelijk gewoon 'Voorwaarden', maar nog niets ligt vast.

Verder werden zoals beloofd nu de oude (50.000+) privé berichten verwijderd (zie eerder nieuwsbericht).

Meer sneak-a-peaks zullen ongetwijfeld volgen de komende weken.

Ps: wisten jullie trouwens dat enkele van jullie (niet-crewleden) het nieuwe project al gezien hebben? Maar deze mogen er natuurlijk nog niets over vertellen...

Ps: volgende post zullen we weer wat meer details onthullen.

Tot snel,
Je CP-team

Het leuke is dat deze kleine seconde meer impact heeft gehad uiteindelijk dan de y2k bug, van het jaar 2000, waar wel zoveel over werd gecommuniceerd en doem scenario's over werden geschreven (xD)

Fijne 4th of July iedereen!

Dit is een Amerikaanse feestdag, om te vieren dat de onafhankelijkheidsverklaring werd ondertekend en dat ze de Britten uit hun land hebben verjaagd.

In België kleden we daarom Manneken Pis in een typisch Amerikaanse outfit.
Doen jullie iets speciaals of kennen jullie acties voor deze 'independence day'?

Vorig weekend werd er 1 extra seconde bij toegevoegd aan alle klokken.
Hoewel dit iets vrij normaals is, zijn er hierdoor verschillende grote websites (LinkedIn, Reddit, Gawker, Foursquare, Yelp, ..) toch gecrasht omdat deze uitzondering niet was voorzien.

Ook enkele vliegtuigmaatschappijen hadden er moeite mee. De luchtvaartmaatschappij Qantas moest zo'n vijftig vluchten vertragen omdat het computersysteem de passagiers niet meer kon inchecken.

Het is nodig om de schrikkelseconde toe te voegen. Als we dat niet zouden doen, zouden onze nakomelingen over honderden jaren hun lunch om middernacht houden. Dit komt omdat de Aarde alsmaar trager rond zijn as draait.

De laatste keren dat de schrikkelseconde werd toegevoegd waren in 1998, 2005 en 2008.

Ken jij iemand die last heeft gehad van deze schrikkelseconde?
Wij zijn er zonder kleerscheuren doorheen gekomen (h)

Beste leden,

Wegens routing problemen bij de ISP waren onze servers gisterenavond tussen 21:30 en 00:30 niet bereikbaar.
Ze doen er alles aan om dit in de toekomst te voorkomen.

Sorry voor dit ongemak en bedankt voor je begrip,
Het CriminalsPoint team

Plesk, het webhosting paneel dat door duizenden grote webhosting providers wordt gebruikt, slaagt zijn wachtwoorden in platte tekst op.
Zo kan iedereen die de server hackt, alle wachtwoorden van iedereen te weten komen.
Plesk zou op meer dan 250.000 servers geïnstalleerd zijn.
Aldus beveiligingsonderzoeker Denis Sinegubko.

Enkel in de laatste versie, die recent werd gelanceerd, worden wachtwoorden versleuteld.

Werk jij of jou hosting provider met plesk, vraag hem dan te updaten naar versie 11.
Zoniet is je wachtwoord niet veilig.

jopitan: standaard zet directadmin remote toegang voor je db af, dus daar zit je goed.
Maar standaard zet directadmin er ook phpmyadmin op.
Als die remote toegankelijk is, ben je alsnog de pineut.

Je kan natuurlijk je phpmyadmin beveiligen met een htpasswd file, zodat je apache eerst een wachtwoord vraagt, voor het mysql wachtwoord wordt gevraagd.

Sure, met volgende code kun je testen of je server potentieel hackbaar is voor deze bug:
http://pastie.org/4064638

De bug zelf zit in de memcmp.

Ik gebruikte wamp.

Hey allemaal,

Recent werd er een nieuwe bug ontdekt in MySQL, waardoor je 1 op de 256 keer met een verkeerd wachtwoord toch succesvol kunt inloggen.
Dit is een vreselijk domme bug...

Verwacht wordt dat hierdoor de komende weken veel databases zullen gehackt worden en gegevens zullen worden gestolen.

Draait je server op volgende systemen, dan ben je zeer waarschijnlijk kwetsbaar:
Ubuntu Linux 64-bit ( 10.04, 10.10, 11.04, 11.10, 12.04 )
OpenSuSE 12.1 64-bit MySQL 5.5.23-log
Debian Unstable 64-bit 5.5.23-2
Fedora ( via hexed and confirmed by Red Hat )
Arch Linux (unspecified version)

Volgende systemen lijken vooralsnog niet kwetsbaar:
Red Hat Enterprise Linux 4, 5, and 6 (confirmed by Red Hat)
CentOS using official RHEL rpms
Ubuntu Linux 32-bit (10.04, 11.10, 12.04, likely all)
Debian Linux 6.0.3 64-bit (Version 14.14 Distrib 5.5.18)
Debian Linux lenny 32-bit 5.0.51a-24+lenny5
Debian Linux lenny 64-bit 5.0.51a-24+lenny5
Debian Linux lenny 64-bit 5.1.51-1-log
Debian Linux squeeze 64-bit 5.1.49-3-log
Debian Linux squeeze 32-bit 5.1.61-0+squeeze1
Debian Linux squeeze 64-bit 5.1.61-0+squeeze1
Gentoo 64-bit 5.1.62-r1
SuSE 9.3 i586 MySQL 4.1.10a
OpenIndiana oi_151a4 5.1.37
FreeBSD 64-bit (many versions)

Hopelijk is jullie systeem veilig.
Wij hebben er in elk geval geen last van, heb onze servers getest.

Sterkte!

Héhé, ons nieuwe project haalt nog een lagere score dan CP.
Maar goed, daar moeten we nog beginnen met alle optimalisaties te doen :p
Dat doen we op het einde pas.

We weten al dat je bezig bent met een game creator

Ik ben vrij goed in .htaccess
Zie niet meteen wat er fout is.
Buiten dat je .nl.nl hebt staan, 2x .nl dus.
Verder goed rekening houden dat je in de url exact de / gebruikt en niet de \ tekens, aangezien je de forward slash in je rewrite regels gebruikt.

Ik zal nog wat tips geven:
- het probleem is niet de ruimte op de harde schijf
- het probleem is niet het aantal records
- het probleem is niet dat het iets vertraagt
- het is ook niet buitenaards
- en het is super logisch als je er toch op komt

(c)

Laat je ook zeker niet verleiden tot Amerikaanse hosting.
Je bezoekers worden eerst de oceaan over gestuurd en dan weer terug.
Heb een tijd lang daar websites proberen te hosten, maar elke site was gemiddeld 4 tot 5 seconden trager in laden dan hem in NL of BE te hosten!
Voor je filmpjes kun je dit wel overwegen, aangezien deze minder snelheids kritiek zijn.

Indien je dit zou willen testen, kan ik wel een hosting met onbeperkt traffiek en ruimte regelen voor je in Amerika.

Misschien zorgen ze op een andere plaats wel voor problemen?

De 50mb is natuurlijk niet zoveel en die 100.000 records zijn ook geen probleem.