Recently, after refactoring some Rust code, I noticed that it had suddenly become four times slower. However, the strange part is that I didn’t even touch the part of the code that became slower. Furthermore, it was still slower after commenting out the changes. Curious, I decided to investigate further.
The first step was to use git diff to display all changes since the previous commit, which was normal speed. Then I started removing them one by one, no matter how inconsequential, and testing to see if it was still slow after the change.
Adding the print statement causes the code to go from 0.16 seconds to 1.7 seconds, an 11x slowdown (in release mode). Then, I posted it in the rustc IRC channel, where eddyb and bluss suggested a workaround and explained what was going on.
The fix was to the change the print line to the following, which does indeed fix the slowdown.
If you use GNOME or Ubuntu, then GNOME Disks is probably what you rely on if you ever need to do any disk management operations, so it’s a relatively important piece of software for GNOME and Ubuntu users. Now if you’re a command line geek, you might handle disk management via command line, and that’s fine, but most users don’t know how to do that. Or if you’re living in the past like Ubuntu and not yet using Wayland, you might prefer GParted (which does not work under Wayland because it requires root permissions, while we intentionally will not allow applications to run as root in Wayland ). But for anyone else, you’re probably using GNOME Disks. So it would be good for it to work reliably, and for it to be relatively free of bugs.
The GNOME desktop environment is loved by many, but it allows for very little out-of-the-box customisation. However, you can extend the features of the desktop by installing third-party extensions which help to fix any weird quirks you might have observed or change the behaviour of your desktop outright.
I got to completely geek out when Daniel Matte wrote up the things he found about Andromeda while looking through some Google source code earlier this week. It reinforced a lot of the things I thought when I first looked through all the code in August 2016, caught a lot more things that I overlooked, and examined the new code. I think Matte's assessments are pretty close to the mark here. Not because they confirmed some of my original thoughts, but because it points out things I got wrong. Or at least I think I got them wrong. Everything about Andromeda or Fuchsia is still just educated guessing.
Linux Mint 18.1 Serena is an okay distro. It has more merit than Sarah, but then, it's also had almost a year to work on polishing some of the issues, and while a few have been ironed out, big quality issues that were never the domain of Mint before still persist. The live session experience is underwhelming, the default theme is not vibrant enough and can lead to ocular exhaustion quickly, there were problems with stability, multimedia playback, and the promise of Spotify never came to be.
On the other hand, most of the stuff works out of the box, the repos are rich, the distro can be tamed relatively easily, and at the end of the day, you have a supported, popular system full of goodies and shiny colors with only a slight aftertaste of betrayal in your proverbial mouth. Good, but only if you've just started playing around with Linux. This distro has no flair. It doesn't have the magic and fire of yore. No fire, no nothing. It's not super green. And it must pop pop pop. So I guess, grade wise, 6.5/10 or some such. All in all, 'tis Linux Mint all right, but not the best offering by a long shot.
Also: Linux Mint 18.2 Features – What’s Ahead In the Next Release
Wiki pages are great for collaboration. But they are not that great in getting people’s attention. They can also become pretty messy and hard to navigate trough when using multiple pages that are related to each other – like documentation – which was what we had there. We needed something better. Something that would make it easy to go trough multiple pages of documentation. Something that would have a simple landing page explaining what we do. And having a simple way to review the changes people make before publishing them would be also great.
I knew we wanted something better, but I didn’t know what exactly. I also didn’t want to invent yet another way to build docs. So I looked around, and found the Fedora Release Engineering documentation. It’s hosted in Pagure Docs, it’s built with Python Sphinx, and it also used to be a wiki. And I got inspired!