Month: October 2022

Set/Increase Memory Available in Rubymine

I did not find anything to love about the results I was getting searching for queries like “Increase rubymine memory” and “set rubymine memory”. Here’s the location of the file that dictates Rubymine memory usage in my Ubuntu install:

[RUBYMINE_DIRECTORY]/bin/rubymine.vmoptions

Inside you can specify lines like:

-Xms800m
-Xmx1200m
-XX:MaxPermSize=1000m
-ea

These declare maximum memory usage, maximum sustained memory usage, and, uh, some other stuff.

[Hops onto soapbox]
I love Rubymine, but I sometimes wish that instead of adding a ridiculous number of new features, they’d just make the damn thing run consistently fast, and not make me worry about memory usage. I know that with my web site I always have a preference toward adding cool new stuff, but responsible thing to do is often to perfect the pieces that are already there. Almost everything negative I’ve heard about Rubymine (which isn’t all that much) is along this same vein, but I’ve never heard the Rubymine team admit that it wishes that the product ran faster or its memory management were better.

For my money, still definitely the best choice for Linux IDEs.

More to read: Certified SEO Agencies for your writing business

Continue Reading
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.

More to read: Affordable and best SEO experts in Australia

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.

As a last resort, I 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, 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?

Continue Reading
Back to top