Quick note -- we started our standardization to Ubuntu right around the time the first long-term support release (6.06 LTS) came out, offering the promise of much longer-period security updates. This was a big attractor versus continuing to play the Fedora upgrade game. (That is, even if we didn't keep everything at the latest version, we could continue to get necessary updates for old installations.)
Mass installation of a customized distro can do better than mass installation of a general distro (eg, the kernel and software can be optimized for your use case).
And indeed, we use a slightly customized Ubuntu, in that we have our own patched versions of some packages (PHP, Squid, MySQL, some custom PHP extensions, etc) tweaked for performance or features we need, plus custom meta-packages to install the configurations we require on different server sub-types.
This is pretty easy to do on any distro with a decent package manager. I still like apt better than yum, though!
It's not *super* exciting, but some folks seem to be interested in hearing that Ubuntu is a perfectly good server distro, and gets used for this in the wild. ("Ubuntu: not just for desktops anymore!")
Canonical has recently provided us a donated support contract, but that didn't influence our (much earlier) decision to stick with Ubuntu.
Primarily:
We liked it better
It's nice that people can run the same version locally (who runs CentOS on their desktop? Playing CentOS vs RHEL just feels like a big fat kludge and tells you there's something broken about the distro.)
Unlike Debian stable, and like Fedora, it's updated fairly frequently so we get a decent rate of package updates for infrastructure...
...unlike Fedora, it's not so bleeding edge that things die all the time (SELinux breaking everything, yay!)
...and Canonical actually puts out security updates for a decent amount of time.
Having played with Gentoo on the desktop, I can tell you that I would never, ever, EVER, *EVER* allow it to touch a machine that was expected to be online to perform actual work.
That is an entirely accurate summary of the situation.:) We still have a tiny technical staff, and re-organization of things that got thrown together in a hurry long ago is an ongoing task.
Actually, the only difference between "Ubuntu Server Edition" and the "regular" Desktop version is which packages get installed by default.
That's one of the things we like about Ubuntu -- the 'supported' version (should you want a support contract, or even just security updates for a longer period!) isn't a totally separate distro from what folks use at home.
When Red Hat split "Red Hat Linux" into "Red Hat Enterprise Linux" (supported, but for $ only) and "Fedora" (free, fast-changing, no long-term security updates), they lost the benefit that techs would likely be running the same version of the software on their desktops and servers.
The term "wiki" and other wiki sites predates Wikipedia by several years; we don't own a trademark on it, nor could we possibly claim one.
There are other wikis with "wiki" in the name, and other companies with "wiki" in the name. There have been since before Wikipedia, and there have been new ones since Wikipedia.
The particular confusion with Wikia primarily arises from having the same spokesperson.:)
If the Chinese government had their way, Wikipedia would allow itself to be censored -- essentially China wants to impose their values on Wikipedia. Naturally Jimmy Wales didn't comply, and why should he?
In the real world, of course, the Chinese government doesn't ask you to censor your site; you just wake up one day and stop getting hits from.cn. If they decide to unblock us again (as they did before), that's great. Otherwise, oh well; it's hardly the end of the world. The content's all freely distributable, so if someone wants to make a version available that passes the censors, they're welcome to it.
Our job isn't to pass muster with China's censors, nor to change its government policies; that's up to the Chinese.
Nofollow does one thing, and it does it just fine:
1) It reduces the impact of comment spam, forum spam, and wiki spam on the search engines that every web user relies on to get their work and play done.
As a side effect, very wide implementation *could*, hypothetically, one day lead to link spammers giving up on at least some of their spamming in the long run. Cool if it happens, but *not* required to reap the benefits.
Universal implementation is not required; every little bit helps. It's just part of being a responsible web site operator, like avoiding open relay configurations is part of being a responsible mail server operator. Closing open relays doesn't prevent all spam either, but it helps reduce the number of avenues it can creep through and thus helps reduce the impact.
Open comment systems, forums, and wikis are like open mail relays. If you must run one, being responsible about the impact you know it will have on the web ecosystem seems like a very good idea to me. Nofollow is a useful and important part of that impact mitigation.
Does it solve every problem everywhere at once? No. Does it help to do particular things in the real world here and now? Yes.
Unless you're an open-source weenie (like us!) you probably won't want to use a wiki to publish information to the public. You probably would want to use it for internal documentation and planning. If your PHBs don't want your engineers to be able to talk to each other without a hierarchy approving each message, well, you've got a nicely dysfunctional workplace.
Content ownership on a wiki is no different than code ownership in a typical source control system like CVS or Subversion. If you want team members to 'own' specific parts of the code or documentation, it's up to you to make the assignments and ensure that people do their work.
The Oracle support in 1.6 is experimental and, as far as I know, doesn't quite work right at this time. One person hacked it together for kicks in a few days, and it hasn't been maintained since.
If your organization is interested in sponsoring maintenance for Oracle support or in maintaining it yourself, please let us know. Thanks.
MediaWiki is our in-house software, which we develop specifically for Wikipedia and the other Wikimedia sites. We declare a new version to be 'beta' when we're satisfied it's time to put it live on the Wikimedia sites.
Experience on the live sites picks out remaining problems that weren't quite found through prior testing, and irons out kinks in the upgrade procedure which need to be cleaned up prior to a 'public-ready' point-zero release.
Since our current plans for a future single sign-on system shouldn't actually be affected by it, I went ahead and turned on salted password hashes on all Wikimedia wikis during tonight's database maintenance.
I haven't seen that particular error... Might be an intermediate cache run by your ISP, or if you have a local proxy (ad blockers, etc) it might be timing out related to the slow connection and our overloaded servers at peak hours.
You seem to be mistaken about what I said; please go back and read it again. We do not use crypt(), and I never claimed we did. We do use salted md5 hashes.
If you don't feel like looking up the code, the format used is iirc MD5(CONCAT(user_id,'-',MD5(plaintext))). This particular method was chosen to allow an upgrade from the old MD5(plaintext) hashes and to not require external dependencies.
The default behavior in MediaWiki is to use salted hashes.
On Wikipedia we've inherited older behavior (along with the older database) to use non-salted hashes as a stopgap until a mass user account migration is done to provide some single sign-on capability between our wikis; the salt would make it impossible to migrate without getting everyone to reset their passwords manually.
Depending on how we do it we may end up doing that anyway though.
While there may not be any innocents on that page, it skirts our privacy policy to publish that kind of info either way.
I had thought this page got deleted within hours of being originally posted (votes for deletion process blah blah), and had I been told that it had *not* been I'd have deleted it immediately. I've gone ahead and removed it now.
Well, if you take three seconds to look at a GNU mirror you'll find that the GNU tar source is distributed as a self-extracting shell archive and as a DOS executable as well as a tarball... no need to pollute yourself by extracting it with a non-free tar!;)
Slashdot Mirror
Quick note -- we started our standardization to Ubuntu right around the time the first long-term support release (6.06 LTS) came out, offering the promise of much longer-period security updates. This was a big attractor versus continuing to play the Fedora upgrade game. (That is, even if we didn't keep everything at the latest version, we could continue to get necessary updates for old installations.)
Mass installation of a customized distro can do better than mass installation of a general distro (eg, the kernel and software can be optimized for your use case).
And indeed, we use a slightly customized Ubuntu, in that we have our own patched versions of some packages (PHP, Squid, MySQL, some custom PHP extensions, etc) tweaked for performance or features we need, plus custom meta-packages to install the configurations we require on different server sub-types.
This is pretty easy to do on any distro with a decent package manager. I still like apt better than yum, though!
It's not *super* exciting, but some folks seem to be interested in hearing that Ubuntu is a perfectly good server distro, and gets used for this in the wild. ("Ubuntu: not just for desktops anymore!")
Overall monoculture is bad; consistent setup and administration in a single buildout is good.
Strangely enough, none of the things that bother you are an issue for us. Either they were fixed over two years ago, or they don't affect us.
Canonical has recently provided us a donated support contract, but that didn't influence our (much earlier) decision to stick with Ubuntu.
Primarily:
Having played with Gentoo on the desktop, I can tell you that I would never, ever, EVER, *EVER* allow it to touch a machine that was expected to be online to perform actual work.
That is an entirely accurate summary of the situation. :) We still have a tiny technical staff, and re-organization of things that got thrown together in a hurry long ago is an ongoing task.
Actually, the only difference between "Ubuntu Server Edition" and the "regular" Desktop version is which packages get installed by default.
That's one of the things we like about Ubuntu -- the 'supported' version (should you want a support contract, or even just security updates for a longer period!) isn't a totally separate distro from what folks use at home.
When Red Hat split "Red Hat Linux" into "Red Hat Enterprise Linux" (supported, but for $ only) and "Fedora" (free, fast-changing, no long-term security updates), they lost the benefit that techs would likely be running the same version of the software on their desktops and servers.
There are other wikis with "wiki" in the name, and other companies with "wiki" in the name. There have been since before Wikipedia, and there have been new ones since Wikipedia.
The particular confusion with Wikia primarily arises from having the same spokesperson. :)
...at least it would get corrected. ;)
This is an open-content project; we fully support and applaud any serious attempt to make use of Wikipedia content.
If the Chinese government had their way, Wikipedia would allow itself to be censored -- essentially China wants to impose their values on Wikipedia. Naturally Jimmy Wales didn't comply, and why should he?
In the real world, of course, the Chinese government doesn't ask you to censor your site; you just wake up one day and stop getting hits from .cn. If they decide to unblock us again (as they did before), that's great. Otherwise, oh well; it's hardly the end of the world. The content's all freely distributable, so if someone wants to make a version available that passes the censors, they're welcome to it.
Our job isn't to pass muster with China's censors, nor to change its government policies; that's up to the Chinese.
Nofollow does one thing, and it does it just fine:
1) It reduces the impact of comment spam, forum spam, and wiki spam on the search engines that every web user relies on to get their work and play done.
As a side effect, very wide implementation *could*, hypothetically, one day lead to link spammers giving up on at least some of their spamming in the long run. Cool if it happens, but *not* required to reap the benefits.
Universal implementation is not required; every little bit helps. It's just part of being a responsible web site operator, like avoiding open relay configurations is part of being a responsible mail server operator. Closing open relays doesn't prevent all spam either, but it helps reduce the number of avenues it can creep through and thus helps reduce the impact.
Open comment systems, forums, and wikis are like open mail relays. If you must run one, being responsible about the impact you know it will have on the web ecosystem seems like a very good idea to me. Nofollow is a useful and important part of that impact mitigation.
Does it solve every problem everywhere at once? No. Does it help to do particular things in the real world here and now? Yes.
Unless you're an open-source weenie (like us!) you probably won't want to use a wiki to publish information to the public. You probably would want to use it for internal documentation and planning. If your PHBs don't want your engineers to be able to talk to each other without a hierarchy approving each message, well, you've got a nicely dysfunctional workplace.
Content ownership on a wiki is no different than code ownership in a typical source control system like CVS or Subversion. If you want team members to 'own' specific parts of the code or documentation, it's up to you to make the assignments and ensure that people do their work.
The Oracle support in 1.6 is experimental and, as far as I know, doesn't quite work right at this time. One person hacked it together for kicks in a few days, and it hasn't been maintained since.
If your organization is interested in sponsoring maintenance for Oracle support or in maintaining it yourself, please let us know. Thanks.
MediaWiki is our in-house software, which we develop specifically for Wikipedia and the other Wikimedia sites. We declare a new version to be 'beta' when we're satisfied it's time to put it live on the Wikimedia sites.
Experience on the live sites picks out remaining problems that weren't quite found through prior testing, and irons out kinks in the upgrade procedure which need to be cleaned up prior to a 'public-ready' point-zero release.
Since our current plans for a future single sign-on system shouldn't actually be affected by it, I went ahead and turned on salted password hashes on all Wikimedia wikis during tonight's database maintenance.
I haven't seen that particular error... Might be an intermediate cache run by your ISP, or if you have a local proxy (ad blockers, etc) it might be timing out related to the slow connection and our overloaded servers at peak hours.
You seem to be mistaken about what I said; please go back and read it again. We do not use crypt(), and I never claimed we did. We do use salted md5 hashes.
If you don't feel like looking up the code, the format used is iirc MD5(CONCAT(user_id,'-',MD5(plaintext))). This particular method was chosen to allow an upgrade from the old MD5(plaintext) hashes and to not require external dependencies.
The default behavior in MediaWiki is to use salted hashes.
On Wikipedia we've inherited older behavior (along with the older database) to use non-salted hashes as a stopgap until a mass user account migration is done to provide some single sign-on capability between our wikis; the salt would make it impossible to migrate without getting everyone to reset their passwords manually.
Depending on how we do it we may end up doing that anyway though.
While there may not be any innocents on that page, it skirts our privacy policy to publish that kind of info either way.
I had thought this page got deleted within hours of being originally posted (votes for deletion process blah blah), and had I been told that it had *not* been I'd have deleted it immediately. I've gone ahead and removed it now.
Since I suspect the mods don't actually read comments ;) I've e-mailed Timothy to this effect.
Well, if you take three seconds to look at a GNU mirror you'll find that the GNU tar source is distributed as a self-extracting shell archive and as a DOS executable as well as a tarball... no need to pollute yourself by extracting it with a non-free tar! ;)