4 posts tagged “update”
Ich baue gerade den Kernel für FreeBSD 7.0 (Release) neu und musste gerade lachen, weil das so entspannt läuft - ich weiss gar nicht wie das mal enden soll. Erstens geht alles, und zweitens hab ich eine DRAC (Dell Remote Access Console) im Server.
Und wenn man ungefaehr 30x (nach make installkernel) die folgende Meldung sieht ...
... dann darf man sie ignorieren.kldxref: file isn't dynamically-linked
(Edited.)
After bumping up the PHP 5.2.x on one of our servers Friday night, I got reports from some of our clients that certain websites would not work anymore. After investigating this problem, I found that most all of the my problems were in Joomla, Mambo and Drupal plugins/extensions which those people used.
Of course no offense to those three systems (and their developers and people using them ;-)), but I googled the error and found that many people reported similar issues on support forums of those three. At least the top results suggest that. On the list of offenders are also shops such as the very popular OSCommerce. Anyway - just let me stress this again - no offense meant (but you need to fix your code :-P).
On to the fix.
The offending code, could look like (this example is from Mambo's AKO_Book extension):
Digging into this, you will probably find a class that would look similar to this:MENU_Default::MENU_Default();
At first I (paniced and) thought that effectively all static calls without a "static" keyword are broken in PHP5.2.5. But after investigating and raising a bit of havoc on IRC and internals@ (Sorry!), Bjori shed some light into/onto my confusion and figured out that this is just a static call to the constructor of a class.<?php
class MENU_Default {
function MENU_Default() {
// do something
}
}
?>
And calling the constructor of a class directly is just wrong. And static calls to the constructor have not been allowed since 5.0.0. (I am not sure why no one reported issues before but I guess since I wrote our customers that the update was smooth, they just had to dig up something. :-))
The fix is simple and should have been there to begin with:
// currently:
MENU_Default::MENU_Default();// replace with:
new MENU_Default();
Issues like that are to be traced back to PHP4's more 'lax interpretation of OO. Even on PHP4 coders should have written the latter, but no one forced them to. And because I know the pain of upgrading a system like Joomla/Mambo, Drupal and others - especially once you put a lot of customization in it, I hope this helps someone out there fix their issues.
Debatable is still if any version of PHP5 should really consider this to be a fatal error. Or if this call should be subject to E_STRICT which was introduced in PHP5 to ensure forward compatibility of code, which sounds like the best fit for this. I believe in the E_STRICT way.
I know and understand that there are probably about a dozen technical reasons to E_FATAL instead, but in my (very) humble opinion to make people aware with E_STRICT and to add a note that E_STRICT will eventually turn into E_FATAL in PHP6 would have been the right path to persue here.
Less breakage and more awareness - they make the "we told you so"-argument more valid. Everything but that just adds to the user's general fear to adopt PHP5 and to finally get rid off PHP4.
On a side note - I feel that I need to add that we only allow those old versions to run because we patched them for our clients and because we use an application firewall called mod_security. mod_security is customizable through rule sets and we constantly update them to combat known attacks (e.g. XSS, comment spam, ...).
If you don't have those resources available to yourself, you need to consider an update of the PHP application more sooner than later.
Here are some things I encountered during my Leopard update.
I had no 10.4?!
The installer initially claimed I didn't have 10.4 (Tiger) installed. I rebooted a couple times (using MS Windows logic), but couldn't get it to recognize the installed operating system. I finally managed to pass this step, by clicking back from the "start" screen where you go back to the initial language selection. Clicked "English" again and then the installer checked once more and found it. This is to be filed in the WTF department.
4 minutes remaining ...
Close to the end of the install, it claims that it will only take four more minutes. Don't get excited yet, and don't worry too much either. Each of those four (Apple) minutes took about 20 (real) minutes to pass.
Perl goodness
Whenever I open a shell now it says:
I'm not sure where this error comes from. I have tried to install them through fink, but I am now in the process of fixing fink first (gcc seems to have disappeared) and will let you know what I find later on. If anyone has a clue, feel free to comment.perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LC_ALL = (unset),
LANG = "UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
Aside from those quirks the update went pretty well. And Leopard is pretty awesome. I totally dig spaces, stacks, the new preview feature and (of course) time machine. It looks pretty slick too.
- ... a bigger harddrive because I currently have only 10 GB free space and Vista needs at least 15 GB but likes to occupie 40 GB
- ... a better video card.
- ... to buy more RAM because I currently have only 512 MB and Vista recommends at least 1 GB.
- ... a DVD drive, or order Vista on CDs.
- ... to update my TrackPoint's driver, because it will stop working otherwise.
- ... to buy a new printer, because my 8-week-old Samsung ML-1610 is not on the list of supported devices
- ... to update just about every little IBM tool which makes my Thinkpad worthwile
Pretty cool, huh? Or rather not cool at all! If you want to check your own computer, check out the Vista Upgrade Advisor.
On Monday I will check if they have an Upgrade Advisor for my Mac Mini at work.
