Profile cover photo
Profile photo
Michael Aaron Murphy
What do you see when you reverse the chessboard?
What do you see when you reverse the chessboard?


Distinst now has the ability to perform automatic installs alongside existing operating systems. Once this PR is merged, it should be trivial to implement support in the UI frontend and shipping in future ISO releases. The only thing holding it back at the moment is the need for testing.

This PR is also waiting to be merged for the installer. Recent work in distinst has been perfecting the ability to perform automatic installs, and migrating more code from the installer frontend into distinst. Performance and reliability should be greatly improved, as a result. This, along with the other PR, are the stepping stones needed to implement more complex automatic installation methods.

Other Linux distributions, take note. distinst / installer are aiming for the top, in regards to the Linux distribution installer field.
Add a comment...

Pop!_OS is going to have an advantage on the Oryx Pro 4 over Windows: Pop!_OS's power daemon will be capable of fully powering off the NVIDIA GPU when switching to Intel graphics. There's some sort of Windows + NVIDIA agreement disallows for the NVIDIA graphics chip to be fully powered off on Windows after switching to Intel graphics.

Due to the upcoming release of the Oryx Pro 4 (oryp4 & oryp4-b) models at System76, I spent the day patching GNOME Initial Setup to provide some important information regarding that when that hardware is detected. Nothing more than a visual and a small amount of information to highlight how to switch between Intel & NVIDIA in the shell.

Since GNOME Initial Setup is written in C, I decided to go along with that and implemented the logic in C. Red Hat's usage of builder XML UI files in the project is confusing, however (can't be opened in Glade, so requires manual editing of XML). XML is a very verbose format for designing layouts and setting properties, and GNOME does not have much in the way of error handling for invalid UI files. Seems like it would have been easier to write and maintain the UI in C.

If I ever need to do anything more serious than a custom summary screen, I'll definitely reach to integrate Rust into the project.
Add a comment...

I've been busy with a lot of things since the release of Pop!_OS 18.04.

I was tasked with creating a basic Plymouth splash screen (pop-basic) that focuses exclusively on providing a decent password screen for systems with LUKS-encrypted devices. It was made with the script plugin and a custom Plymouth script. It's effectively just the GDM background color with a password entry with a slow-blinking cursor, and a few custom icons alongside the entry with a text prompt underneath to hint the user at what they're trying to unlock. The UI scales based on resolution of the device.

Big improvements have been made to Popsicle to increase the responsiveness and improve the maintainability of the source code through some much-needed refactoring. For example, when you are on the USB device selection view, the view will automatically update as devices are added and removed. Also made a few UI changes on some things that were bothering me regarding the padding of widgets on the flash view.

Have also submitted two PRs to the power daemon to give it some new features -- currently under review. One is for supporting profiles that remember backlight settings when users switch between profiles, and another is for automatically switching profiles based on battery status. Hence me releasing the upower_dbus crate recently.

I've also recently been introduced to the firmware side of System76. Jeremy walked me through the process of obtaining the firmware, editing the firmware, signing the firmware, and then creating an image to flash live hardware with. It's actually a pretty simple task with the infrastructure that he made.

The Debian repo utility that I created was also updated to support updating its own configuration. If the necessary info is provided within the TOML config, it can update software in the repo automatically.

The installer has seen even bigger improvements, gutting much of the Vala code and replacing it with better implementations in Rust from the distinst backend. Support for language locales and countries is drastically superior than before, so now effectively every language has associated countries to select from, and a larger list of countries. I've also implemented support for reviewing keyboard layouts in the UI, as I noticed that it was not functioning (note that all of this only applies to pop-os's fork of elementary's installer).

Distinst has seen some refactoring as well, some of which comes from creating macros for repetitive tasks. I did try to make the C FFI simpler with macros that generate functions, but this effort went into limbo due to issues with cbindgen and macro expansions. I could probably solve it by using a simple trick with Cargo, but it would require a Nightly version of Rust to use the expand=pretty feature.

There's been some work on supporting hardware detection and selecting packages to install based on the detected hardware, in addition to the opening the door to supporting other Linux distributions outside of Debian-like distributions. To make it easier to maintain in the future, macros have been developed here so that people can easily slip in their distro specifics and package names to match.

There's also been some work on the recovery partition idea, which currently works pretty well, but will work even better with some additional work in that area to advance the capabilities of the recovery partition.

I've currently been working on support for additional installation types, and automatic installation capabilities. Rather than defining routines within the installer frontend, defaults are going to be defined within distinst, which will directly result in even less reliance on Vala. In addition to a default install option, there will be a refresh option that will be able to carry over user accounts from the previous install, and all of their files in `/home`. Other possibilities might also be possible, but I haven't yet thought of how to handle multiboot scenarios in an automatic way (distinst has the infrastructure to pull it off, though).
Add a comment...

Post has attachment

If anyone wants to interact with UPower info via the Dbus interface in Rust, I released a tiny crate this morning that will let you achieve that. I haven't yet exposed all the available properties and methods, but the most important ones are there at the moment.

1. Check if a system is on battery
2. Get the active battery energy total in Wh
3. Get the active battery energy in Wh
4. Get a percentage of the active battery energy level

Will be getting integrated into the system76-power daemon in the future, so that it can react to battery levels.
Add a comment...

A study on the energy efficiency of various programming languages. C is the most energy efficient on average, so it was given a value of 1.00. Rust only needs 3% more energy, and 4% more time. The kicker is the third place language: C++. It not only needs 34% more energy, but 54% more time.
Add a comment...

Post has attachment
Add a comment...

Post has shared content
Pop!_OS 18.04 LTS is here! #trypopos and see all the new features that make this Pop!_OS upgrade even better. With Full Disk Encryption, a Do Not Disturb feature, and enhanced battery level indication you have more control than ever before. Be a switcher with Optimus switching and easy HiDPI/standard DPI switching allowing you to better manage your workspace. Upgrade now, or preview the new features at
Add a comment...

Currently working on Debian packaging-related utilities, in Rust. Today I have a simple tool that reads a TOML spec and builds a Debian repository from it. It only supports direct downloads and just amd64 at the moment, but I'd like to see it expand to encompass much more than that. And since this is Rust, the packages are verified and downloaded in parallel.

The examples directory includes a demonstration of how it works. Simply run the tool from within that directory, after changing the email field, and it will generate a complete Debian repo for you. You would then be able to add that to your /etc/apt/sources.list, like so:

deb [arch=amd64] file:/mnt/data/Sources/debrepbuild/examples bionic main

Note that you do need to have a GPG key in order to get your repo signed.
Add a comment...

Post has attachment
This is interesting. A case study performed by the Rust developers, focusing on Chucklefish's experiences with Rust on their new game.
Add a comment...

Post has attachment
Wait while more posts are being loaded