I figured out how to do some slight video editing in OpenShot, and have tried to make another Wikisource tutorial:
I’ve been moving all my photos to Flickr lately. It’s been a long process, one complicated by the fact that it seems silly to run my own WordPress installation (and things like ArchivesWiki) if I’m not going to bother hosting everything myself. Of course, that’s not really very logical, and so I’ve decided that it’s perfectly okay to host photos on Flickr, videos on YouTube, and all the text (and miscellaneous) stuff here on my own server.
There are a few mistakes here, and as I’ve yet to figure out how to edit videos properly (I’ve only managed to hang my video editing software so far), they’ve stayed in; I’ll do another video correcting things.
The pagelist creation process is probably the hardest bit for beginners to Wikisource, and it’s something we need to work on. Metadata copying, on the other hand, mostly works fine (of course, we should not be copying the metadata, but that’s another story).
Today is All The Stations‘ “have an adventure” day, in which they’re asking people to visit a railway station that they’ve never been to before. When I first heard about it I figured I have to end up at somewhere boring like Aubin Grove but as it turns out I’m actually at Wikimania in Montreal! So it’s rather easy to find a station to which I’ve never been; in fact, with the assistance of a friend, I have today been to seven new stations.
Place d’Armes (no photo).
And also Windsor, which isn’t actually a station any more:
And rain, I mustn’t forget the rain. I’m worrying about the roof, although far less than I used to (it’s a different roof). The jazz is the radio; it’s on.
But the main point this morning is exploring the mediawiki-lts package maintained by Legoktm. I’ve been meaning to look at it for a while, and switch my (non-playground) wikis over to it, but there’s never enough time. Not that there’s enough time now, but I’m just trying to get it running locally for two wikis (yes, the smallest possible farm).
So, in simple steps, I first added the PPA:
sudo add-apt-repository ppa:legoktm/mediawiki-lts
/etc/apt/sources.list.d/legoktm-ubuntu-mediawiki-lts-xenial.list. Then I updated the package info:
sudo apt-get update
And installed the package:
sudo apt install mediawiki
At this point, the installation prompt for MediaWiki 1.27.3 was available at http://localhost/mediawiki/ (which luckily doesn’t conflict with anything I already had locally) and I stepped through the installer, creating a new database and DB user via phpMyAdmin as I went, and answering all the questions appropriately. (It’s actually been a while since I last saw the installer properly.) The only tricky thing I found was that it asks for the “Directory for deleted files” but not for the actual directory for all files — because I want the files to be stored in a particular place and not in
/usr/share/mediawiki/images/, especially as I want there to be two different wikis that don’t share files.
I made a typo in my database username in the installation form, and got a “Access denied for user x to database y” error. I hit the browser’s back button, and then the installer’s back buttons, to go back to the relevant page in the installer, fixed the typo and proceeded. It remembered everything correctly, and this time installed the database tables, with only one error. This was “Notice: JobQueueGroup::__destruct: 1 buffered job(s) of type(s) RecentChangesUpdateJob never inserted. in /usr/share/mediawiki/includes/jobqueue/JobQueueGroup.php on line 447”. Didn’t seem to matter.
At the end of the installer, it prompted me to download LocalSettings.php and put it at
/etc/mediawiki/LocalSettings.php which I did:
sudo mv ~/LocalSettings.php /etc/mediawiki/. sudo chown root:root /etc/mediawiki/LocalSettings.php sudo chmod 644 /etc/mediawiki/LocalSettings.php
And then I had a working wiki at
I wanted a different URL, so edited
/etc/apache2/sites-available/000-default.conf (in order to not modify the package-provided
/etc/mediawiki/mediawiki.conf) to add:
Alias /mywiki /var/lib/mediawiki
And changed the following in
$wgScriptPath = "/mywiki";
The multiple wikis will have to wait until later, as will the backup regime.
Is it a coincidence that Jeremy Corbyn on Dead Ringers is rather similar-sounding to their Brian Cox?
I’ve been reading about POSSE and PESOS, and getting re-inspired about the value in a plurality of web tools. I sometimes try to focus just on one Software package (MediaWiki, at the moment, because it’s what I code
for at work. But I used to love working on WordPress, and I’ve got a couple of stalled projects for Piwigo lying around. Basically, all these things will be of higher quality if they have to work with each other and with all the data silos (Facebook, Twitter, etc.).
The foundational principles of the IndiWeb are:
- Own your data.
- Use visible data for humans first, machines second. See also DRY.
- Build tools for yourself, not for all of your friends. It’s extremely hard to fight Metcalfe’s law: you won’t be able to convince all your friends to join the independent web. But if you build something that satisfies your own needs, but is backwards compatible for people who haven’t joined in (say, by practicing POSSE), the time and effort you’ve spent building your own tools isn’t wasted just because others haven’t joined in yet.
- Eat your own dogfood. Whatever you build should be for yourself. If you aren’t depending on it, why should anybody else? We call that selfdogfooding. More importantly, build the indieweb around your needs. If you design tools for some hypothetical user, they may not actually exist; if you build tools for yourself, you actually do exist. selfdogfooding is also a form of “proof of work” to help focus on productive interactions.
- Document your stuff. You’ve built a place to speak your mind, use it to document your processes, ideas, designs and code. At least document it for your future self.
- Open source your stuff! You don’t have to, of course, but if you like the existence of the indie web, making your code open source means other people can get on the indie web quicker and easier.
- UX and design is more important than protocols, formats, data models, schema etc. We focus on UX first, and then as we figure that out we build/develop/subset the absolutely simplest, easiest, and most minimal protocols & formats sufficient to support that UX, and nothing more. AKA UX before plumbing.
- Build platform agnostic platforms. The more your code is modular and composed of pieces you can swap out, the less dependent you are on a particular device, UI, templating language, API, backend language, storage model, database, platform. The more your code is modular, the greater the chance that at least some of it can and will be re-used, improved, which you can then reincorporate.
- Longevity. Build for the long web. If human society is able to preserve ancient papyrus, Victorian photographs and dinosaur bones, we should be able to build web technology that doesn’t require us to destroy everything we’ve done every few years in the name of progress.
- Plurality. With IndieWebCamp we’ve specifically chosen to encourage and embrace a diversity of approaches & implementations. This background makes the IndieWeb stronger and more resilient than any one (often monoculture) approach.
- Have fun. Remember that GeoCities page you built back in the mid-90s? The one with the Java applets, garish green background and seventeen animated GIFs? It may have been ugly, badly coded and sucky, but it was fun, damnit. Keep the web weird and interesting.
There will be a workshop at the State Library of Western Australia this Saturday from 1 p.m., for anyone to come along and learn how to add just one citation to just one Wikipedia article (or more of either, of course). For more details, see meta.wikimedia.org/wiki/WikiClubWest.
Five years, two months, and 22 days after the last time, I’m retiring my laptop and moving to a new one. This time it’s a Lenovo ThinkPad Carbon X1, fifth generation (manufactured in March this year, if the packaging is to be believed). This time, I’m not switching operating systems (although I am switching desktop’s, to KDE, because I hear Ubuntu is going all-out normal Gnome sometime soon).
So I kicked off the download of
kubuntu-16.04.2-desktop-amd64.iso and while it was going started up the new machine. I jumped straight into bios to set the boot order (putting ‘Windows boot manager’ right at the bottom because it sounds like something predictably annoying), and hit ‘save’. Then I forgot what I was doing and wondered back to my other machine, leaving the new laptop to reboot and send itself into the Windows installation process. Oops.
There’s no way out! You select the language you want to use, and then are presented with the EULA—with a but ‘accept’ button, but no way to decline the bloody thing, and no way to restart the computer! Even worse, a long-press on the power button just suspended the machine, rather than force-booting it. In the end some combination of pressing on the power button while waking from suspend tricked it into dying. Then it was a simple matter of booting from a thumb drive and getting Kubuntu installed.
I got slightly confused at two points: at having to turn off UEFI (which I think is the ‘Windows boot manager’ from above?) in order to install 3rd party proprietary drivers (usually Lenovo are good at providing Linux drivers, but more on that later); and having to use LVM in order to have full-disk encryption (because I had thought that it was usually possible to encrypt without LVM, but really I don’t mind either way; there doesn’t seem to be any disadvantage to using LVM; I then of course elected to not encrypt my home directory).
So now I’m slowly getting KDE set up how I like it, and am running into various problems with the trackpoint, touchpad, and Kmail crashing. I’ll try to document the more interesting bits here, or add to the KDE UserBase wiki.