4 ms·

Poor Wikipedia will need to migrate back to php7 runtime which still could be complex despite of language compatibility.

kreetx 8y ago
Interestig fact that Wikipedia runs on hhvm! But I guess since php7 appears to be as fast if not faster nowdays then it's probably the right move anyway.
- Washuu 8y ago
  MediaWiki has to support PHP 7 for the community of wikis outside Wikipedia that use it. If they dropped PHP 7 support they would be making MediaWiki a bit of an insular project.
  - debacle 8y ago
    Or Facebook could sponsor their development on hhvm and use that to promote hack lang.
    - Washuu 8y ago
      Then every single third party extension developer would also have to move to Hack. Knowing what I know about certain extension developers that will never happen and a hard fork of MediaWiki will occur.
beberlei 8y ago
Wikipedia was always a PHP software and just running on HHVM for the performance gain, not for the Hack language. The underlying MediaWiki software is used outside of Wikipedia a lot, always on the PHP not HHVM stack. I expect its only a project for their operations team and should be managable.
- piotrkubisa 8y ago
  Could you tell more about MediaWiki use-cases outside Wikipedia? I know there is a lot of open-source projects which has MediaWiki installed for documentation (i.e. Arch Linux). Are there any usage in "internal documentation" software (like alternative to Confluence)? Why they have chosen the MediaWiki not other software which can be easily self-hosted / deployed on a premise?
  - beberlei 8y ago
    I dont know much about that, but in a previous job 6 years ago we saw mediawiki in quite a few non technical companies used as internal doc system
  - codewiz 8y ago
    MediaWiki is indeed very easy to self-host. I've been running several instances for the FSF and Sugar Labs. From the sysadmin perspective, it's a dream app to deploy: just unpack (or git clone) the latest release in a directory, point Apache (or Nginx) at it, and continue in the guided setup process (which involves creating a database, typically MySQL). Updates are also painless: there's a php maintenance script which updates the schema. I've kept MW instances for ~10 years without running into any problems. Things get a little more interesting if your add a ton of extensions, or badly maintained ones. I wish I could say the same of Django and Rails apps! <trollface>

kreetx 8y ago

Interestig fact that Wikipedia runs on hhvm! But I guess since php7 appears to be as fast if not faster nowdays then it's probably the right move anyway.

Washuu 8y ago
MediaWiki has to support PHP 7 for the community of wikis outside Wikipedia that use it. If they dropped PHP 7 support they would be making MediaWiki a bit of an insular project.
- debacle 8y ago
  Or Facebook could sponsor their development on hhvm and use that to promote hack lang.
  - Washuu 8y ago
    Then every single third party extension developer would also have to move to Hack. Knowing what I know about certain extension developers that will never happen and a hard fork of MediaWiki will occur.

beberlei 8y ago

Wikipedia was always a PHP software and just running on HHVM for the performance gain, not for the Hack language. The underlying MediaWiki software is used outside of Wikipedia a lot, always on the PHP not HHVM stack. I expect its only a project for their operations team and should be managable.

piotrkubisa 8y ago
Could you tell more about MediaWiki use-cases outside Wikipedia? I know there is a lot of open-source projects which has MediaWiki installed for documentation (i.e. Arch Linux). Are there any usage in "internal documentation" software (like alternative to Confluence)? Why they have chosen the MediaWiki not other software which can be easily self-hosted / deployed on a premise?
- beberlei 8y ago
  I dont know much about that, but in a previous job 6 years ago we saw mediawiki in quite a few non technical companies used as internal doc system
- codewiz 8y ago
  MediaWiki is indeed very easy to self-host. I've been running several instances for the FSF and Sugar Labs. From the sysadmin perspective, it's a dream app to deploy: just unpack (or git clone) the latest release in a directory, point Apache (or Nginx) at it, and continue in the guided setup process (which involves creating a database, typically MySQL). Updates are also painless: there's a php maintenance script which updates the schema. I've kept MW instances for ~10 years without running into any problems. Things get a little more interesting if your add a ton of extensions, or badly maintained ones. I wish I could say the same of Django and Rails apps! <trollface>