HowITreatCovid19.com

The pandemic has meant for me a sudden halt in my clinical rotations at the hospital and confinement at home. It was rather frustrating to see the crisis unfold in our healthcare system and especially in our senior’s residences and stand here by the sidelines. However, I soon found a way to partake in this vast effort to fight off Covid-19 by volunteering along with dozens of my peers for the HowITreatCovid19.com project:

Our website is dedicated to helping healthcare professionals find accurate and up-to-date information about the best ways to manage and treat patients affected by the COVID-19 outbreak.

How I Treat Covid-19 banner

Most other volunteers dedicated themselves to sifting through the vast amounts of scientific publications coming out each day. As for myself, I renewed with my previous job as a web developer and got busy building the platform and some of it’s editorial processes.

Every little bit (of code) truly helps in this fight.

Access control list (ACL) extension on MediaWiki

MediaWiki is meant to be an open platform and was not conceived with fine-grained access control in mind (like ACL). For most cases, that’s ok, but on a project I’m working on I’ve felt the need for keeping some parts of my wiki private and secure from indirect access using transclusions or searches.

In order to achieve that, I’ve entirely revamped the Semantic ACL extension, which had been left unmaintained for some years, but had great potential.

Here’s the list of features (more will be added when needed):

  • Works through transclusions: If a page is transcluding a page or a subset of the page that has a protection in place, users not allowed to view that content will see a placeholder message instead.
  • Works with files: If a file is protected, users not allowed to see the file will be denied access to the file page and will see placeholder content where the file is used in other pages. If a file is uncategorized or part of category that an anonymous user is not allowed to see, placeholder content will be displayed instead.
  • Works with search results: Search results including a page that a user is not allowed to see won’t display the content of the page, only its title.
  • Works with Structured Discussions and talk pages: A talk page or a structured discussion will get the same protection as its associated content page.
  • Works within the wiki: No need to edit LocalSettings.php to modify restrictions, everything is done from inside your wiki.
  • Works with many use cases: Restrictions can be enabled for anonymous/registered users, user groups or individual users.

All the docs are on the extension’s page.

Wikimedica: une plateforme collaborative de transfert des connaissances médicales en libre accès

Le Journal médical de l’Université d’Ottawa publie mon article sur Wikimedica dans son numéro sur les innovations médicales. Merci!

Résumé:  La médecine moderne ne peut plus se pratiquer sans l’aide de bases de connaissances cliniques. Or, toutes celles disponibles sont payantes et fermées et s’il est un domaine qui pourrait bénéficier d’un accès libre à de l’information fiable, de qualité et à jour, c’est celui de la santé. Wikimedica (http://wikimedi.ca) est une plateforme libre accès conçue à cette fin qui permet tant aux cliniciens de terrain qu’aux étudiants de collaborer dans la création et l’amélioration des connaissances essentielles à leur professions.

Abstract: Modern medicine cannot be practiced without the help of basic clinical knowledge. However, all that is available is payment based and restricted, and if ever there was a field in which one could benefit from free-access to trustworthy, high quality and up to date information, it would be healthcare. Wikimedica (http://wikimedi.ca) is a free-access platform created for this purpose which allows working clinicians and students to collaborate on the creation and the improvement of the knowledge essential to their professions.

Moving Linux on a windows drive for dual booting

README! There are many use cases for dual booting and guides for achieving it, this one concerns moving an existing Linux to a drive on which Windows is already installed and dual booting them. In other words, you will be combining existing Windows and Linux systems to coexist on the same hard drive.

I’ve been using the same hard drive for a while and transporting it from laptop to laptop whenever one would fail me (you can do that with linux). Now, after 8 years, I was fearing it was the actual hard drive that would break next so this time, I had to move my actual operating system to another physical disk.

Wanting to be able to dual boot into windows as well, I was stuck in a scenario for which there was not much help on the web. Here’s what I did:

  1. Resize your Windows partition using the disk management tool to make room for Linux and its swap. The new Linux partition must be larger that the one you are moving from.
  2. Reboot to a Linux live CD or GParted and create a bootable Linux and a swap partition (they must be primary) after the Windows partition.
  3. Clone you existing Linux OS partition from the old hard drive to the new.
    1. Plug in your old drive (external SATA, external disk case, extra hard-drive bay, etc.) but leave it unmounted.
    2. dd if=/dev/sdXY of=/dev/sdWZ bs=1M

      where XY is the drive letter and partition of the Linux OS you are moving from and WZ those of the partition you are moving to.

    3. Wait for a while, depending on the size of the partition, this could take a bit because you are cloning every single byte from one partition to the other. In my case, it tool a good solid two hours and half.
  4. Unmount and disconnect your old Linux OS hard drive. In case something goes wrong, simply popping it back in your computer will restore your setup just the way it was before.
  5. Mount your new Linux partition.
  6. From within the Live CD, restore the GRUB2 bootloader by executing
    grub2-install --root-directory /mountPoint /dev/sdW

    where mountPoint is where you new Linux partition is mounted and sdW is the drive where it resides.

  7. Since the partition’s GUIDs have changed you need to update the /etc/fstab file on your Linux with the new ones. Any file editor will do. Look up the new GUIDs for your new OS and swap partitions by running
    ls -al /dev/disk/by-uuid/
  8. Remove the live CD and restart the computer.  From within GRUB2’s boot menu, you should only see your Linux and not Windows, that’s normal. Boot your Linux OS.
  9. Run
    grub-mkconfig -o /boot/grub2/grub.cfg

    GRUB2 will scan your hard drive, find the Windows install and create a new boot configuration file. Now, when you reboot your machine, you will see Windows within the boot menu menu entries.

  10. Finally, since the size of the underlying partition holding your Linux installation has changed, the size of the file system has to be updated as well:
    resize2fs /dev/sdW

Done! Moving operating systems around and getting them to cohabit alongside each other is tricky and far from being straightforward so I hope this guide worked for you. You will most likely have to adapt it to your own situation and if you feel something you did could benefit others, please comment.

Fixing AMD (ati) radeon display issues on Fedora

Note (09/01/17): also worked on a recent upgrade from 23 to 25.

I had put off system upgrades for so long that I found myself having to go from Fedora 20 to 23. It took a while but everything was going smoothly until I hit Fedora 23 on. There, after the mandatory reboot, hooking up my secondary monitor would freeze the display and screen repainting on some programs (like Eclipse) had become problematically slow and CPU demanding. This being Linux, I scoured the web on a quest to find some clues on what was not configured correctly but nothing came up. I’m running an AMD A6-3420M APU and while AMD provides driver for that chip, they are according to reports very finicky and a pile of trouble to get running.

I resorted to simply downgrading the driver. It was working correctly in the past, so I could see no obvious reason an older version would not do it this time.

First find the version of the driver currently installed:

dnf info xorg-x11-drv-ati

Which should spit out something along the lines of:

Installed Packages
Name        : xorg-x11-drv-ati
Arch        : i686
Epoch       : 0
Version     : 7.6.0
Release     : 0.4.20150729git5510cd6.fc23
Size        : 151 k
Repo        : fedora
Summary     : Xorg X11 ati video driver
URL         : http://www.x.org
License     : MIT
Description : X.Org X11 ati video driver.

So the faulty driver is version 7.6.0. Now, run:

sudo dnf --showduplicates --allowerasing --releasever=24 downgrade xorg-x11-drv-ati

Here, we’re asking dnf to go look in a previous release of Fedora for an earlier version of the driver. If the problems you are experiencing appeared with a recent update, you could avoid the –releasever argument altogether to just revert back to the previous version.

If the downgrade does not work, you rerun the command to roll back the driver even further in the past, but if after a couple times you haven’t had success, the issue probably lies with another package so run a dnf update to and take your investigation elsewhere, maybe the kernel, wayland, X, the window composer or gnome-shell.

When you update your system in the future, you’ll have to run:

sudo dnf --exclude=xorg-x11-drv-ati update

Otherwise, dnf will reinstall the broken later version of the package. This command will also give you packages with broken dependencies. That’s normal, those are packages that share dependencies with the one you have downgraded and for all I know could actually have been the ones causing you trouble. Just let them be.

Make sure you check back from time to time if another version of the offending package has been released by issuing a simple dnf update and checking the version now available.