Brion Vibber is a user on mastodon.technology. You can follow them or interact with them if you have an account anywhere in the fediverse. If you don't, you can sign up here.

Brion Vibber @brion@mastodon.technology

And while merging a separate patch we may have discovered a bug or oddity in our CI system, where we can't test the backported safari patch because another patch on master landed that removed a dependency that's still used on branch. Why oh why do I merge just one more patch after 5pm

Found that Safari 12 was breaking on our WebM video playback; looks like it's applying the same anti autoplay tech for Web Audio that was previously in Safari for iOS.

Workaround is the same: start some null node in your AudioContext from an interaction event handler, and keep that context around until your stuff is loaded and ready to play.

In my code I just had to remove the iOS check and let it always run the workaround, and it's working now on both iOS and macOS Safari.

Esperanto Show more

But I would love to have something like flatpak for installing potentially competing versions of CLI things outside the base but in a reproducible, nicely packaged way.

Come to think of it, flatpak would probably work for ffmpeg. ;)

I think Linux distros get the versioning problem 'wrong' for CLI stuff as well as GUI apps.

When you need an updated tool (ffmpeg) that needs an updated lib (libvpx) you end up backporting packages, or else you go outside the system and build manually (which Ops won't put up with, sensibly!)

I'm a reasonably clever person but Debian packaging just confuses the bejeebus out of me at the best of times! Luckily at Wikimedia we have a few people who know the process well, so we should get it sorted out soon.

Getting close to a long-held dream: switching Wikimedia's video playback from old VP8/Vorbis to newer VP9/Opus flavor of WebM, for significant disk and bandwidth savings.

It will slow down latency of encoding unless we update ffmpeg/libvpx to enable using more encoder threads, which will require some package backporting but shouldn't be too hard.

mediawiki.org/wiki/Extension:T

So apparently WSL exists on Windows 10 for ARM, and can run the Aarch64 edition of Ubuntu 18.04! That means a Win10 ARM laptop would actually be something I could work on while traveling, without lugging a Mac or Linux laptop along.

Might be worth waiting for the Cortex-A76 based processors to hit market, but I may not be able to stop my early-adopter/collector factor. ;)

blogs.msdn.microsoft.com/comma

Accidentally tried to print from Linux again last night. This not only doesn't work, it appears to crash the printer's queue manager without any visible error, requiring a hard printer reboot before I can print from macOS. !

Now that I'm *trying* to get the mac to crash on the nvidia gpu it's running stable like a rock. 🤔

Well, if nouveau just doesn't trigger the state change that makes it crash, I guess that'll be fine?

I know I used to have frequent crashes on this machine in Linux when I tried a couple years ago, but that might have been with nvidia's blob driver.

(On macOS I used a utility app to force the integrated GPU to minimize the crashes.)

Eh, now can't get nvidia working on EFI boot either. We'll just see how it goes, if I have to switch back to llvmpipe that's ok for my expected usage of this machine. :D

Ok, it seems that in BIOS boot mode, Linux sees only the Nvidia and not the Intel GPU, so disabling nouveau driver forces it to llvmpipe on top of Vesa mode setting. Hah!

If I re-enable nouveau it sees native panel resolution, but I'm pretty sure it'll crash after a few minutes or couple hours of usage.

Going to re-test under EFI boot, see if I can get it to see both and then disable nouveau there?

One funky thing is it's only picking up 1280x800 but the panel native res is 1440x900. Meh. My eyes ain't that great anyway...

Dumped the old EFI and apple recovery partitions and just let Fedora take the whole disk. Seems happier, boots up and everything. Yayyy!

Fourth problem: Fedora's installer gives a warning about sda being too small to hold core.img when setting up partitioning if I leave the EFI partition in place.

Turns out that grub in BIOS mode stores some of its boot stuff in the space before the first partition, but a lot of old disks have relatively little space there.

I manually moved around the EFI and apple recovery partitions so there were 2048 sectors before sda1 instead of just 40. It seems happier and is currently installing...

Third problem: EFI boot doesn't seem to enable the Intel GPU or something else is wrong? With nouveau disabled on boot line it never reaches the GUI.

So... Use the BIOS boot emulation (says "Windows" in the apple boot selector), disable the nouveau module, and we've got a working GUI live DVD.

Second problem: EFI boot terminal vs grub command line editing. It says Ctrl+x to save but this just inserts an x.

Press F10 instead -- the help text used to include it but it was removed by upstream grub2 because serial consoles didn't work with F10 always. Now we're booting into Linux!

I've got an old 2010 MacBook Pro with the notoriously crashy dual GPU option (the crash is apparently caused by a hardware problem when changing power saving states in a certain way). Since it's being end of lifed by macOS 10.14, I figured I'd throw Linux on it and see if it's usable without enabling the buggy nvidia GPU.

First problem is that this old model won't boot off of USB thumb drives. No really! I had to burn a DVD-R of Fedora 28 and boot to that...

Also found that Theora videos containing duplicate frames seem to break the decoder in edge. Having some trouble with the edge issue tracker to formally report it. We've moved most video output to VP8 already but some source videos are Theora and could end up playing direct in some circumstances.