Posted on

Native emoji support (color emojis) in arch Linux

If you’re on Arch, and you use sites with native emojis like Amplenote, you probably get pretty tired of seeing empty black boxes wherever emojis are supposed to be. However, Google isn’t especially forthcoming about the easiest path to fix that.

My experience is that what you want is the ttf-emojione package from AUR. The easiest way to install it is via the Add/Remove Software app:

If the command line is more your speed, you should be able to install it via yaourt -S ttf-emojione

After you’ve installed the package, you’ll need to log out and log in for the emojis to show in their full color glory. Here’s a test of whether your handiwork was successful: 🤔🤔🤔

Posted on

Linux touchpad like a Macbook: progress and a call for help

The note sourced to create this blog post lives here. I’ll copy updates to the blog from that note every so often, but the note will be more updated. And the note has a couple footnotes this version doesn’t support. That aside…

It’s taken me longer than I’d hoped to craft a follow up to my viral blog post on… Linux touchpad drivers (what a weird sentence to write). I’d hoped to find 10 or 20 people who shared my belief that Linux touchpads are in a sorry state. Turns out, a niche OS with a subjective quality issue is — in this case — a topic that’s important to thousands. So much so that several commenters on the last blog indicated willingness to donate time or money to improve the plight of this beleaguered driver.

If this collective will can be harnessed, we have a golden opportunity for developers to escape the limitations imposed by modern Apple hardware. Hardware manufacturers are doing their part. There are already laptops that compare favorably against Macbook on tech specs and price. Now, we “just” need software that approximates the fit-and-finish of using a Macbook. Modern day Linux is getting very close: my most recent Linux laptop is the first I’ve ever owned where waking from sleep mode reliably works. ☕

The crux of the challenge is that we need to objectively fix a subjective problem. After spending the past year examining the challenges, here’s how I think we can do it:

Define the goal

To create a touchpad solution for Linux that serves as many users as possible, we want to be maximally objective in describing what we aim to deliver.

My first idea to be objective was to quantify how the cursor worked on OS X, and create a suite of tests we’d use to guide development. That turned out to be a misadventure, for circumstantial reasons.

My second idea is my current preferred plan forward:

1) to fork libinput (overview doc, contributor docs, source), and

2) find up to three developers dedicated to making a measurably better driver.

Why start from libinput instead of building from scratch or another driver? The following line of reasoning from Peter Hutterer (libinput maintainer), persuaded me:

Don’t start from scratch. your goal is for this to be eventually used, at which point libinput is your only option. for any other approach you’ll have to a) stick to xorg only or b) convince every wayland compositor to implement support for your driver (and that you’ll maintain that driver for the upcoming future). given that Fedora already defaults to Wayland, a) isn’t really an option and b) is not likely to happen.

In addition to its Wayland integration, libinput is already built to support Xorg via xf86-input-libinput.

Why three developers for six months? Because any more than three developers A) is unrealistic to expect B) harder to coordinate C) leaves responsibility too open-ended. Why six months? Because the Static Object’s metrics suggest that should be enough time to make a significant impact on this project [footnote describes gradual pace of progress in project]. It’s easy to imagine we could begin seeing noticeable improvements to touchpad tracking accuracy within a couple months of starting development.

I believe the most serious flaw in my plan is the subjectivity around how, specifically, the cursor should behave. Practically speaking, we won’t be able to perfectly clone Apple’s touchpad behavior. So, in place of an objectively provable target, we’ll work from a shared set of intentions:

Project deliverables

  1. Linux touchpad scores on par with Macbook touchpad per mouseaccuracy.com testing. As of today, I can consistently score twice as high on macOS (average score 250 with “Hard” + “Small” options) vs Linux (average score ~100).
  2. Visual or terminal-based means to configure rudimentary touchpad settings. The fewest options I could imagine supporting for v1 would be: scroll speed/acceleration, scroll speed, natural scrolling toggle, hopefully support for gestures.
  3. First-class palm and thumb detection/ignoring
  4. Possess a means to submit bugs and have them addressed (via Github issues)
  5. “Feels like a Macbook” to greatest extent possible

We would seek to achieve these modest goals only on modern laptop hardware, eg purchased within last 2-3 years. Broader support should follow.

This project’s grand vision will be realized when its users forget it exists. 🎉

Next steps

What are the next steps on the Linux touchpad roadmap?

How I will help this move forward

  1. Accountability updates. If this post succeeds in wrangling a couple developers to move this project forward, I commit to posting at least one public update per quarter on the status of the project.
  2. Functional quality assurance lead. I will monitor our progress toward the “Project Deliverables,” and help coordinate QA resources during development.
  3. Corporate fundraiser. Reach out to companies that would stand to benefit from sponsoring better Linux touchpad performance, provided others can point me toward the appropriate contacts.
  4. Information conduit. I’ve collected about 20 notes worth of information about Linux touchpad drivers over the past year. Perhaps some of these would assist new project participants trying to get up to speed?

Help I need from others to move forward

Can you help advance this cause? Here’s what we need:

  1. Commit to hack on the project. We need 1-3 developers who can commit to pursuing the Project Deliverables over at least 3 part-time months (preferably 6-12 months). I can coordinate matching developers skills to areas of project need. Since libinput is mostly composed of C, experience in that language will be a big plus.
  2. Got contacts? If anyone reading this knows the decision makers at companies who might like to support a popular project, help me out with an e-intro? If we can find a benevolent corporate ally (Microsoft? Google?), we could potentially leverage their resources to fund a full time developer for some months.
  3. Evaluate Chrome OS touchpad driver. See my “Tangential Opportunity to Help” memo. I consider this avenue a longshot to be the long-term solution for a Linux touchpad driver, but in the short term, it might be a viable driver for Linux users until the long-term solution is built.
  4. Got knowledge? I’ve become a lot more of a Linux touchpad expert than I’d ever hoped, but there are still people like Peter who know a lot more than I do about the interplay between the kernel, Wayland, and the input driver. I’d love to have contact info for a couple experienced Linux OSS-familiar devs who could accelerate my future research.

If you can help with any of these: please drop a line in the blog comments, or email bill at staticobject.com

Into a future less bound to Apple’s whims

All of the above plan is subject to change if better evidence/ideas are presented. I’m a pragmatist at heart, and the proposed plan is the most realistic path I can conceive to deliver a better Linux touchpad experience before the end of 2019. There’s low-hanging fruit to be picked. The touchpad driver most Linux users are currently utilizing (libinput) is developed part time, by a single developer (thanks Peter!).

There’s never been a broad mandate to make Linux touchpads pleasant to use. With your help driving attention to this issue, we can change that.

Posted on

Measuring developer productivity in 2019

Until I spent the better part of 50 hours writing this guide about measuring developer productivity, I had little appreciation for how far we’ve come in the past four years. If you’re an engineering manager, there’s a growing body of data that suggests you can make a blanket increase in engineering efficacy. If you’re a great developer, you now stand to earn your due. These are exciting times to be programming.

Additional topics covered in the (admittedly a bit too epic) guide:

If you manage developers, would love to hear what you think of this effort? Is it relevant to you? Anything that could make it better?

Posted on

Linux touchpad like a Macbook: goal worth pursuing?

Following is my proposal to improve the state of Linux touchpad drivers. It’s a cause I have spent almost a year of my spare time researching in depth. The first section, below, surveys the landscape of today’s available Linux touchpad drivers. The second section (“The Journey Here“) gets into greater depth describing the current failings of available choices. The third section (“The Path Forward“) proposes my best ideas for how we might be able to realize a Linux touchpad driver with polish level matching a Macbook Pro.

A survey of today’s Linux touchpad drivers

For the last 6 months, I’ve been trying to configure a Dell Precision laptop running Arch to get the same feel as the Macbook Pros I loved until the Touchbar Era. I started with the Arch default, libinput. I gave up on it in about a week, when I determined that something as simple as controlling the two-finger scroll speed was not included in the available options. The default was about 3x faster than the comfortable speed I’ve grown to love with my Macbooks. Had I not been disuaded by scroll speed, I might’ve still abandoned ship for the lack of scroll gliding (a feature I never knew I’d been using until it was taken away), which apparently I have Strong Opinions about.

Linux being Linux, I figured that I’d have a universe of touchpad drivers to choose from, each with its own awkward UI that would be confusing and painful to use, but ultimately get the job done. What I discovered instead was all of three options: one of which I had just eliminated (libinput), one that has been abandoned by its maintainers in favor of libinput (synaptics), and a third that was also abandoned by its maintainers, with zero graphical UI left behind (mtrack).

I’m writing this blog because I appreciate the nuances of how the Macbook touchpad performs, but the Touchbar Era has taught me that it sucks to have my user experience tied to the whims of a singleminded hardware company. I want to be part of the solution to create a Linux touchpad driver that’s indistinguishable from the Macbook, and has at least a minimal UI to accommodate the most common differences in user preference. I believe this would bring Linux hardware a big step closer to owning the same panache that makes the Macbook experience special. All evidence collected to date suggests that my mission may well prove quixotic. But if other people care about this, it could get done. I posit my ideas on a path forward here. If you’ve got time and want to learn more about what informs my opinions on the best path forward, read on…

The Journey Here

After realizing libinput wasn’t going to work for me, I found this blog post, whose title seduced me (“The perfect (almost) touchpad settings on Linux”). I went on to write my own follow up blog post, after discovering that the initial blog post left much to be desired compared to the Macbook standard I longed for. When it came to scroll speed and scroll glide, mtrack performed like a champ. Graphical UI be damned, I spent minutes — eventually hours — parsing the documentation. Between the 1,001 options available, I was optimistic about my prospects to recreate my Macbook utopia. And I would’ve done it, if not for the wretched nuisance I’d come to call “Cursor Nudge.” In a nutshell, “Cursor Nudge” is the phenomenon by which the center point of your depressed thumb will glide by a few millimeters as a natural effect of transitioning from the “move cursor” position to the “depress” position. None of mtrack’s 1,001 options could conquer Cursor Nudge, and eventually I grew weary of clicking right next to my target.

Down to my final shot, I really wanted synaptics to work. Yeah, it was abandonware, but it was abandonware that had been forsaken due to its multitude of options. A multitude of options seemed to be what I needed to replicate the Macbook. Initial results were promising: Cursor Nudge was not an issue with Synaptics. In fact, for my first few days using it, I found it pretty bearable. I wouldn’t confuse it with Macbook — not without the smooth acceleration and deceleration. Not with only the slighest twinge of scroll glide. Not with the need to click in the bottom right corner to effect a right click. But it was… probably satisfactory. If not for the bugs. About once or twice a day, when I put my thumb down to click or start scrolling, my open document would jerk toward the bottom of the scrollable viewing area. I Googled it. I installed the xinput listener, captured all my tracking input into logs, and tailed the logs to look for patterns that preceded the bug. And then I wondered, “does Apple still sell the pre-Touchbar Macbook?” Turns out, in what I can only interpret as tacit admission of their wrongdoing, they do. It doesn’t have enough RAM, and much of its technology is 10 years old. But its polish level remains eons beyond what I can replicate with Linux, and I refuse to carry around a mouse.

I also emailed the maintainer of libinput (previously maintainer of Synaptics). I asked him what it would take to write a Linux touchpad driver that would approach parity with the Macbook. His take wasn’t optimistic (“unless you raise enough money to hire at least one full-time developer there’s little point”). I have to imagine this is what naturally happens to a developer that has spent large swaths of a career worrying about backwards compatibility and subtle hardware differences. It sounds like a special type of hell he’s dealing with, and I appreciate the heroics that have gone into making a variety of Linux touchpad drivers almost good enough. But, even though I did eventually cave and buy new old Macbook, I’m not resigned to the imperfections of the current Linux touchpad landscape. A friend of mine who doesn’t even work in tech pointed out to me a month ago that he was reading a random post where they linked to my first blog post pursuing a Macbook-equivalent Linux driver. Somebody besides me cares about this.

The Path Forward

Wherein it becomes apparent that the author doesn’t yet know the best solution.

I think a polished driver could only be delivered within a narrow range of parameters. It probably isn’t going to support laptops older than 3-5 years old. It isn’t going to offer 1,001 options. It may or may not be continuously supported. It may use one of the existing drivers as a starting point, even if that starting codebase isn’t “clean” or well-documented.

Could we build something that works better than existing solutions for 95% of users (= developers) for less than $100k? Probably. Do users (or companies) feel enough pain with the Linux touchpad solutions that they’d donate money (or time) to tackle an esoteric issue? That is what I need to find out.

With a sufficiently enthusiastic response to this blog (todo: define sufficient), I would volunteer my own time to spearhead the non-development aspects of a solution [1]. I could create a Kickstarter page, or help PM or QA development efforts on a driver built to mimic Macbook on the widest possible range of modern laptops. I could donate time to whatever better idea you present. But, first I need a hand to determine: does this actually matter?

Update November 2018: Been putting a lot of time into this cause lately. I’m at about 10 notes and counting so far. I should have a proper blog update to post within the next month.

 

[1] I’d rather be programming this than PMing it, but my programmer brain is currently dedicated to quantifying developer activity and counting lines of code

Posted on

Alternatives to Xmarks (now discontinued)

Xmarks (nee Firemarks) has been a reliable companion to address my cross-platform bookmarking needs over the past 10 years. As such, I was saddened to receive word that parent company Lastpass has chosen to discontinue Xmarks as of mid-2018. This sent me on a quest to find the best Xmarks alternative, but the first Google result I was presented (alternative.to) when searching “Xmarks alternatives” contained a spate of services that had precious little relevance to users like myself who simply want the means to save bookmarks in a cross-browser compatible extension, with as few other bells and whistles as possible.

After considerable Googling, here are the top three recommendations I’d present to other Xmarks users being forced to abandon ship:

Eversync

There’s good reason that this is the most-cited service you’ll find (alongside Xmarks) when Googling terms like “cross browser bookmarks.” It supports all the major browsers/platforms (including my current laptop, running Chromium on Arch Linux). It has been doing this long enough to have a quaint (read: “embarrassingly outdated”) little website that imputes the difficulty of building a business with via bookmarking extension.

Eversync’s web site welcomes you to the 90s

Most importantly, it’s got impeccable ratings. As of March 2018, it maintains a 4.5 star rating on the Chrome app store with about 3,000 ratings. I consider this an incredible feat, given that greater volume of ratings typically drive a product’s average toward the 3 stars.

The biggest gripe I have with Eversync is that its creators package a collection of junk like “Speed Dial.” If you’re a power user with more than 500 bookmarks, Nimbus (who appears to have purchased the extension from Everhelper at some point) will try to charge you $45/year for the extension (plus Nimbus bloat). Woe that it does cost money to maintain a web service.

Chrome sync

Ok, technically this isn’t a cross-browser solution. But if you’re like me and you only stray outside of Chrome on occasion (usually to test a page I’m developing on another browser), then the simplest way to sync bookmarks is to simply use the browser’s built-in capability. No extensions to download, no potential that you’re going to have to change managers again when software maker abandons their product.

If you choose this option, you will most likely want to visit your browser’s Settings -> Sync settings and disable the properties that you don’t want or need synced on all of your workstations:

Raindrop.io

This option “only” manages 4 stars on 300 ratings in the Chrome app store, so it’s a half-step below Eversync in terms of its user reputation. I’m including it here anyways because its home page inspires me to believe that its developers are actively working on it, and thus its functionality may be more likely to improve compared to Eversync. Further, it’s list of features including “Duplicate finder” and “Broken link finder” indicate a level of product dogfooding (creator using own product = creation of features to maximize user satisfaction) that was largely absent in Xmarks. For what it’s worth, the Pro version of Raindrop is also a few bucks cheaper than the Pro version of Eversync ($5/month for Eversync vs $3/month for Raindrop).

If anyone has firsthand experience with Raindrop, I’d be much obliged to learn your satisfaction level in the comment section below.