Code Review Tuesday took a little extra long this week. ;) But it’s still 2008 here in California, so let’s get this party started!
And in the next couple days I plan to start rolling out some things that have been in testing, and rolling out new tests of things we didn’t quite get enabled on test yet:
It’s weekly code review update time! :) Some changes of note…
User preferences:
Web standards behavior:
Localization/UI changes:
Upload/file-handling issues:
API changes:
In r44919 I’ve gone ahead and reimplemented bug 2585, so a page view for a nonexistent page will return a “404 Not Found” HTTP status code instead of a “200 OK”.
This will allow bots and spiders to detect broken links from the outside web to bad or deleted wiki pages, but should be totally transparent to end-users.
When we first attempted this in 2005, the 404 was also applied to action=edit pages… We had a large number of reports from active editors that they were having trouble creating articles, with the edit page not loading properly.
Since this was disrupting basic site activity, we ended up reverting it before we had a chance to really track it down — none of the developers could reproduce it at the time.
The size of our base HTML from even the simplest skin should be enough to avoid tripping Internet Explorer’s “friendly error pages”, and we were unable to track down any specific browser, ISP proxy, or other hypothetical problem source.
If people do encounter problems once this goes live, it at least shouldn’t affect primary wiki functionality while we reproduce and fix it — hitting a raw page view for a nonexistent page is something that you usually have to jump through some hoops to do within the wiki.
After things have settled a bit, we’ll probably start using more 4xx and 5xx status codes for various error pages.
We’re trying to provide more aggressive online backups for our office staff, as well as making it easier to do things like uploading big ol’ videos from the WMF office.
Anybody know a good business internet provider in San Francisco that can provide circa 10Mbps up for less than $1k/month?
That’s what we’re seeing looking around so far and it feels pretty steep… :(
Really wishing Verizon FiOS was available in town…
Clearing out old backups, I stumbled on this half-written blog post from 2004 about my “switch”.
While they may not be the most earthshaking issues, I’m disappointed that things have not changed much in four years — I hit the same stumbling blocks when playing with my Linux netbook today…
Last October I got a PowerBook. I’d been mainly a Linux ‘n’ BSD guy for years, bouncing between Gnome, KDE, and alternative desktops every few months, though I’d been using Mac OS X at work for some months.
Instantly the little PB became my sole desktop environment — my poor x86 box sat unused for weeks at a time except as a file server or occasional test machine, despite sporting a faster processor and whatnot.
What was so darn great about the Mac, other than just that it was portable?
I still do much of my file management at a bash prompt rather than in Finder (and I’ve never much liked Nautilus or Konqueror).
Things that are darned good:
Application launching
The way the dock works in Mac OS X is just darn great. Sure there are corner cases where things go wonky, but most of the time it’s the way I like it. Things to note:
- It’s very easy to keep a running application permanently in the dock.
You started something up once or twice, then you decide you’re going to want it all the time and have it available for easy launching. On the Mac, you just drag its icon to the place on the dock where you’d most like to have it.
That’s it.
Nothing more.
No five-level-deep right-click context menu[1]. No trying to figure out the correct command line and which of five ‘standard’ icon directories they stashed the application’s icon in. No hunting down the secret ‘remote’ launcher command so that multiple invocations work correctly.
[1] I’m not shitting you about five levels. That’s how many levels of popup menus I actually had on screen adding Konqueror to my Gnome launcher panel.
OH HOW I WISH this were as easy in Gnome and KDE. Just sort of hope that a .desktop file was installed for you and pray it’s somewhere you can find it.
Even once you’ve got something in your panel/kicker your pain is not over. Rearranging items in the panels is a horrible experience and often ends up with ugly, uneven spacing, stuck drag modes, or other annoyances. Drag and drop sometimes works.
Application switching
After months with the Mac I can’t imagine anymore how anyone lives with a taskbar model. Virtual desktops are necessary just to keep the taskbar manageable. Yuck!
I simply haven’t missed virtual desktops on the Mac. (If I wanted them, there are third party apps that do it.) Nor do I use Exposé very frequently. (But it looks neat!) Most of the time I find it quite sufficient to just switch between applications with command+tab.
The distinction I need to point out is between switching applications on the Mac and switching windows in Gnome/KDE/Windows. I’ll generally be for instance switching between a text editor and a browser (with documentation, say). Having fewer applications to deal with rather than ten billion windows makes this usually a little more manageable.
But, to each their own.
Application distribution
The typical application distribution model on Linux is “the operating system vendor will distribute the app.”
From there I presumably would have gone on to whinge about dependency hell, the virtual impossibility of manual uninstallation of apps from the Unix filesystem hierarchy, and other desktop integration difficulties when installing third-party software.
This week marked a full year since my fiancée and I sold our cars and moved to San Francisco, and we still haven’t felt the need to buy a new one.
That’s a full year without taking a car in for expensive, mysteriously-described maintenance… a year without worrying about the price of gas or parking… a year without ever-rising insurance premiums… a year without a designated driver. ;)
For the most part we just haven’t felt the need to go driving around much. Our daily commutes to work are pretty straightforward by the subway, and most of our day-to-day shopping is within comfortable walking distance (groceries, pharmacy, etc). There’s plenty of restaurants, theaters, and clubs accessible by walking or public transit… and those that aren’t, we mostly just don’t go to. :)
Google Maps has added public transit and walking directions, now both on the web and on the iPhone application, making it as easy to look up directions to unfamiliar locations as it was when we lived in the Florida suburbs.
We have made use of ZipCar hourly rentals, but really not that often; just for a bulk shopping trip here, an out-of-town event there. For a couple trips all the way down to Southern California to visit family we’ve done traditional daily/weekly rentals… After our grueling Thanksgiving drive, though, for Christmas/New Years we’re going to try flying and borrowing a car down there. ;)
We’ve had some pretty unpredictable code deployment schedules lately and I know that’s been a bit confusing and frustrating (especially when bug fixes are backed up!) To regularize this, I’m now instituting a regular weekly update schedule.
Every Tuesday I’ll be doing a code review and deployment prep to get updated MediaWiki code deployed on the Wikimedia sites.
This does mean that Tuesday is probably not a good time to commit large experimental changes — but a great time to be available for cleanup and bug fixes on the changes you’ve been making over the last week. :)
Of course there’s some relation to Bug Mondays… I’m dithering over whether to move the bug day to Wednesday or Thursday, since I know on my end Mondays are often taken up with catch-up and meetings, and people are often kinda busy; further it’s hard for me to prep a Bug Monday during work time when our European and Australian folks have already been through most or all of Monday before I wake up. ;)
Any preferences between Wed and Thurs?
Tim has pushed out a new MediaWiki security release fixing up some XSS and CSRF bugs found by David Remahl of Apple. (Thanks David!)
As part of the update, our security checks for uploaded files have been improved — we now replicate Internet Explorer’s dangerous file type autodetection as closely as possible so we can tell when a file will be misdetected unsafely when downloaded by that popular browser.
Go ahead and download MediaWiki 1.13.3, 1.12.2, or 1.6.11. (Versions from 1.7 to 1.11 are old enough we’re no longer supporting them; we went ahead and pushed an update for 1.6 for the few PHP 4 stragglers out there. Upgrade to PHP 5, you guys! ;)
Update 2008-12-16: The 1.12.2 download and patch files are corrupt. :( You can pull 1.12.2 direct from SVN or update directly to 1.13; if you need a 1.12 download, please wait until a fixed release is built.
Note that release candidates for MediaWiki 1.14 should be coming soon, it’s time for our quarterly release!
I’ve moved my blog to a virtual host on Linode, which in theory should offer similar performance as my old dedicated host at 60% lower cost. Especially if I actually move Wikitech offsite, just my blog isn’t going to be super-stressful. ;)
I like that their host monitor will actually automatically reboot my host if it goes down, which I couldn’t get the folks at Sago to do even when I asked. Making me log in or email them to reboot it when both the monitor and the power-cycle are both computer-controlled is just crazy.
Also upgraded WordPress to 2.7. Whee!
Update: It’s live! We did encounter one more fun bug that affected some bot edits and the ‘undo’ function, but this is now fixed too.
I’ve updated test.wikipedia.org to MediaWiki r44462.. after a couple more hours testing, I’ll push it live to all wikis.
List of items changed since last update from our release notes:
New features
Bug fixes in 1.14
API changes in 1.14
Note the ‘File:’ namespace is ready to deploy but won’t be live there yet since test currently still uses the older message files. It should go live after full deployment. Update: fixed that bug, now it uses the new namespace and all new/update messages are live on test. :D