The Framework Laptop

March 22, 2023 —

A few months ago, I picked up a Framework Laptop for myself.

This was to replace my 2014 15-inch Macbook Pro. The Macbook Pro still works just fine, but it is now officially out of support for Mac OS, plus it is very clear to me that its older Intel CPU just isn't super great for the laptop's aging battery. I can still get 2-3 hours battery life out of it, but it has to be very light usage to get that much time out of it. If I'm being honest, this doesn't feel bad to me for a 9 year old battery! Certainly I've heard of people who's laptop batteries of similar age are faring much worse.

This year I found myself increasingly wanting to pack my laptop up and go someplace else for a few hours or so just to get out of my apartment during the day. Most places I would go to do not have freely available power outlets (or if they do, they are very limited and so there's no guarantee I could get access to one), so I am limited to battery most of the time. When I started doing this, it really highlighted to me how little battery life I could get out of my Macbook Pro when I'm doing some coding stuff. I consistently found that I could only realistically expect to get between 90-120 minutes in these cases, and this would only be possible if I switched my IDE (IntelliJ/CLion) to "Power Save Mode", disabled Wifi and Bluetooth, turned the screen brightness to minimal levels, etc. This wasn't ideal to me as most of the time I headed out to work elsewhere during the day, I would have liked to be able to work for more than two hours at a time.

So, I started looking at laptops. I'd been aware of the Framework Laptop for a while now and I really liked what they were doing, but I was also keenly aware of two major things with them: they haven't been around for long and their laptop's aren't known for having great battery life (especially when compared to Apple's M1/M2 laptops)

At my previous job last year, I did get a chance to use a 16-inch Macbook Pro M1. And I quite liked it actually! It felt like a return to the glory days of Macbooks from the early/mid 2010's, plus it was a very performant machine with excellent battery life. However ...

To cut a potentially longer rambling rant short, I've watched more than one of my Apple computers that are otherwise still perfectly fine and usable machines become officially out of support over this past decade and grown highly annoyed at Apple's practices here. This would be fine if Apple's computers were at least somewhat less consumer-hostile when it comes to self-service repair. To be clear here, I'm not expecting a fully swappable, modular design out of Apple ever, but it would be nice if they would, for example, design their laptops with battery replacement in mind. I'd like to see the same for things like storage and memory. Then I wouldn't need to buy a whole new system just to upgrade my memory and/or storage because I maybe didn't realize years ago when I initially bought it that I was going to want more. This is just ridiculous. I know that the common retort to this kind of criticism of Apple's practices is that they solder everything in for both performance and power efficiency. And, sure, that makes sense on a technical level. But from an e-waste perspective, I just absolutely hate this. And to be honest, I'm not entirely convinced that the technical justification for this is fully justified. Like, yes, it makes a difference, but is it really worth the trade-off? I disagree. But regardless, the point here for me is that I refuse to throw my hard earned money at this kind of company any longer when I have a choice. And, in this case, I do have a choice.

And this is a big part of the reason why Framework stood out in my mind. With a focus on modularity (as much as is reasonably possible for an "ultrabook"-style laptop anyway) enabling the consumer to do self-service-repair as well as upgrade components as needed, I feel like this is a company that is a better match for my own personal values. No, it's not going to be as slick and polished an experience as you'd get with another company like Apple who has many billions of dollars and huge teams to put into their products. But I prefer the idea of using my own meager pool of money to support a company that isn't necessarily treating their products like they are throw-away "appliances" or something of that sort.

And I'd also throw out the idea that if a small startup like Framework can achieve what they've achieved here ... just imagine what a company like Apple could do if they decided they wanted to. Hmm.

My Configuration

The Framework laptop that I now have is configured as follows:

  • CPU: Intel i5-1240P
  • Graphics: Integrated Intel Iris Xe
  • Memory: 2x Crucial 16GB DDR4 3200Mhz
  • Storage: Western Digital SN770 M.2 NVMe 500GB
  • Wifi: Intel AX210 (no vPro) M.2
  • Battery: 3572mAh 55Wh
  • Ports: 2x USB-C, 2x USB-A

I've not run anything other than Linux on it to date. I was debating running a BSD on it (both OpenBSD and FreeBSD have been shown to work fine) but decided to fall back to my usual: Gentoo Linux. I'm a big Gentoo fan, having been using it on at least one system I have sitting around in some form or another since 2005. It's by far the Linux that I am most familiar with at this point.

Some special configurations to note are my kernel boot parameters. This is all currently somewhat commonly documented and recommended by the community for Linux users on the Framework laptop.

  • mem_sleep_default=deep: Sets the default value of /sys/proc/mem_sleep which would otherwise be s2idle. The deep setting makes it so S3 suspend is used which does appear to reduce suspend battery drain.
  • nvme.noacpi=1: This seems to be a common recommendation for Framework laptop users to get better suspend battery life, as I understand it, causing your systems NVMe disk to consume less power during suspend. I've not tested without this to see the difference it makes personally yet.
  • module_blacklist=hid_sensor_hub: This is to work around a known issue where the hid_sensor_hub kernel module automatically sets the display's brightness level based on an ambient light sensor. This functionality works fine, but this kernel module overrides manual display brightness control via the backlight keys (Fn+F7 and Fn+F8) making it impossible to change if you so desire. Preventing this module from loading means the ambient light sensor is no longer used, but gives you full control to manually set the brightness level, which I prefer.
  • i915.enable_psr=0 This disables the "Panel Self Refresh" (PSR) feature in the Intel Iris Xe integrated graphics. Without this option, I was experiencing infrequent random flickering where once in a while the screen would appear to flicker with static or some other garbled mess for less than a second before returning to normal. Not the end of the world, but kinda annoying. The problem with disabling this option is that it is less energy efficient to do so.

Finally, since I've installed Gentoo on this laptop, the other settings of note are in my /etc/portage/make.conf:

COMMON_FLAGS="-march=native -O2 -pipe"
MAKEOPTS="-j16"
VIDEO_CARDS="intel"

Anyway, all of my experiences with this laptop which I've written below are written from this perspective. I cannot comment on how this laptop performs with, for example, Windows, because I have not tried it (and have no interest in trying it).

What I Like

The Form Factor

This laptop is directly comparable to a Macbook Air in terms of size and weight. It's been almost 10 years since I last used a Macbook Air, but from my best recollection the Framework feels just as light. Easy to pick up with one hand. When using it on your lap you just don't notice the weight at all.

Modularity

As already mentioned, the modularity is the big win here that first grabbed my attention. I bought the "DIY" edition which is slightly overselling it really. What this means is that you get a laptop shipped to you that does not have the storage or RAM pre-installed (and you even have the option of not buying either from Framework and instead providing your own). But the rest of the laptop is fully assembled. I guess that's still kind of "DIY."

But yes, you can also very easily swap out the 4 USB ports (because they're just custom designed USB-C "dongles" that happen to plug flush into the laptop). I didn't really need a lot of customization here, so I opted for two USB-A and two USB-C ports.

In addition to the USB-C ports, the storage and RAM, you can also easily swap out the internal Wifi M.2 card if you wish, as well as the motherboard itself, the keyboard, trackpad, display, battery, etc. Everything is designed to be easily removed. There isn't necessarily always going to be some alternative available that you can swap it with currently. For example, there are only two motherboards that Framework provides currently (the original 11th-generation Intel motherboard as well as the newer 12th-generation one which is what I have). As well, I don't think there are any other options for the display either. But still, having the option to easily remove any of these components is useful from a self-service repair perspective. You can easily order replacement parts if you have an accident. If something breaks, I don't need to buy a whole new system. Well, unless the whole system breaks all at once, I guess.

Display

The display is quite nice actually. Probably my second favourite thing about this system. It's a 13.5-inch display with an oddball 2256x1504 resolution which is a 3:2 aspect ratio. This is honestly a huge deal to me. I love this aspect ratio. It is so nice having this extra vertical space available with this small display. Over the past 15+ years I've been longing for some non 16:9 or 16:10 option to become mainstream again. I would love to be able to get a modern 4:3 or 5:4 aspect ratio display in a laptop today. But for now, I'll happily take this 3:2 alternative.

One thing that Mac OS does extremely well here as compared to most Linux environments is HiDPI scaling. I really think Mac OS still is best-in-class here.

The first time I've tried out scaling options in Linux has been with this Framework laptop. I don't care for the full screen scaling options that are available in most Linux desktop environments. The results are ugly unless you go up to 200%, which results in a tiny effective desktop resolution of 1128x752. Gross! But scaling options based on font DPI I think are pretty good with both XFCE and KDE from what I've seen.

In the end I opted for KDE and have set KDE's "global scale" option to 150% which I believe under the hood is changing a bunch of things, including font DPI (for example, with "global scale" set to 150%, if I check the font DPI setting, I can see that it has been changed to 144 already). This all seems to be something much more along the lines of what Mac OS is doing, which is quite nice. I was surprised to see that most Linux applications render appropriately based on these settings. But I have seen a very small number which ignore it and look ultra tiny as a result.

Keyboard

The keyboard in the Framework is very nice. To me it's easily on par with the keyboard in my 2014 Macbook Pro. This is definitely one of the nicest laptop keyboards I've used in recent memory.

Of course, I'd love for someone to make a laptop with a modern equivalent of an old IBM Thinkpad keyboard ... but I know that'll never happen, heh.

Trackpad

I think this is what surprised me the most. I've definitely been spoiled by Macbook trackpads which are still best-in-class as far as I'm concerned. But the trackpad in the Framework is surprisingly good. I was not expecting that. It's hard to compare in a perfectly apples-to-apples way instead of apples-to-oranges which I'm going to end up doing here as I think a big part of the trackpad experience is also how good the software is.

My experience using the Framework trackpad on a Linux system has left me with a strong feeling that it feels pretty close to Macbook-like. The only annoyances I've felt have clearly been software limitations. In particular setting up two-finger scrolling that doesn't make it feel like barely touching the touchpad results in it to scroll 500 pixels instantly has been an experience. It seems like libinput doesn't currently have proper options for this. So I've ended up with an X.org configuration like this which I'm mostly fine with:

Section "InputClass"
        Identifier "touchpad"
        Driver "libinput"
        MatchIsTouchpad "on"
        Option "ScrollPixelDistance" "50"
        Option "ClickMethod" "clickfinger"
        Option "NaturalScrolling" "true"
EndSection

In particular, the ScrollPixelDistance setting is what makes two-finger scrolling feel far less overly-sensitive. But I get the sense that this option is not really intended for exactly this purpose. As well it seems to have a very limited range of allowed values. If I set it too low or too high, it automatically resets to it's default. And this allowed range seems a bit too small for my liking. Which all just adds more to my feeling that I am misusing this option.

But again, this is obviously a software issue, not a hardware issue.

I've read complaints about people accidentally touching the trackpad with their hands while actively typing on the keyboard. I guess some trackpad hardware has some kind of detection for this and is able to intelligently disregard inputs received in this manner? I'm not sure. But regardless, I've not personally experienced this problem with this or any other laptop I've ever owned, so I cannot really comment on this.

Performance

I got my system currently set up with a 12th-generation Intel i5-1240P processor which is the first generation of Intel CPUs where they are now doing this "performance" and "efficiency" core split. This processor is the low-end option that Framework offers and it has 4 performance cores and 8 efficiency cores with 16 threads total.

As well, I loaded it with 32GB of Crucial DDR4 3200MHz (two 16GB modules) and 500GB Western Digital SN770 NVMe storage.

I have absolutely no complaints about the performance of this laptop. I did not need a super speedy laptop that was the best of the best. But, still this feels quite a bit more than adequate for what I need. Which is nice, as that hopefully means it won't start to feel slow anytime soon with the increasing amount of software bloat each year. Hopefully.

As mentioned already, I run Gentoo Linux which means I end up compiling mostly everything from source (which is the price you pay to use the very powerful and flexible "USE flags" feature, amongst other benefits), and this machine chews through package compilation pretty nicely.

Since I also run Gentoo on my other systems too, I can offer some simple comparisons.

System Framework Desktop Mac Pro 2010
CPU Intel i5-1240P (4/8c/16t) AMD Ryzen Threadripper PRO 3955WX (16c/32t) 2x Intel Xeon X5680 (6c/12t each, 12c/24t total)
RAM 2x 16GB DDR4 3200MHz 4x 16GB DDR4 3200MHz 6x 8GB DDR3 1333MHz
Storage WD_BLACK SN770 M.2 NVMe 500GB Samsung 980 Pro M.2 NVMe 500GB Samsung 860 EVO M.2 SATA 500GB
MAKEOPTS -j16 -j32 -j24
/var/tmp/portage tmpfs 24GB 32GB 24GB
Package Compilation Times
sys-devel/gcc 27:43 21:41 45:09
sys-kernel/gentoo-kernel 20:25 9:31 24:57

All of the above package compilations have been performed on systems each with the same -march=native -O2 -pipe settings in /etc/portage/make.conf, as well as all package compilation happening in RAM, via tmpfs mounted at /var/tmp/portage. The packages compared use identical USE flags on each system, and the same package version was compared.

This is not a comprehensive benchmark on performance by any means, but even still it is interesting to me to see how a decade of technological advancement easily overcomes the lack of processor threads (when comparing to the 13 year old Intel Xeon X5680). The significantly faster memory also helps too. Also keeping in mind that under such a long package compilation, the Framework's CPU is definitely running into thermal limitations while the dual Xeon X5680's are running at full speed the entire time.

What I Don't Like

Power Efficiency

The battery life is actually a big step up from my old 2014 Macbook Pro!

I've noticed that I can easily expect to get at least 6-8+ hours of light usage (light web browsing mostly with quite a bit of idle time while reading what's on screen) and around 4 to 5 hours doing active software development work (in my case right now, this is IntelliJ for Java/Clojure or CLion for Rust, and this is without the IDE's "Power Save Mode" enabled like I was having to do with my Macbook).

To hopefully provide a somewhat better idea of what the Framework's battery life is like when doing "real work", over the course of a couple days I ran powerstat while doing some coding work in CLion where I was working on some Rust projects while also referencing documentation, searching for things, etc with Firefox. For these tests I started from a 90% battery charge (I have the battery charge limited to this maximum level in the BIOS) and kept working until I got a "low battery" warning from my system which occurs at 10% charge remaining.

First day:

gered@blarg-laptop ~ $ sudo powerstat -d 10 10 20000
Running for 200000.0 seconds (20000 samples at 10.0 second intervals).
Power measurements will start in 10 seconds time.

  Time    User  Nice   Sys  Idle    IO  Run Ctxt/s  IRQ/s Fork Exec Exit  Watts
12:36:35   0.3   0.0   0.1  99.5   0.0    2   1262    465   10    4   10   6.83 

... (omitted for brevity) ...

17:25:36   0.2   0.0   0.2  99.6   0.0    2    643    336   11    4   12   6.37 
^C-------- ----- ----- ----- ----- ----- ---- ------ ------ ---- ---- ---- ------ 
 Average   2.3   0.0   0.5  97.2   0.0  2.1 3454.1 1260.9 18.6  7.5 18.7   8.58 
 GeoMean   1.4   0.0   0.4  97.2   0.0  0.0 2881.8 1062.5 13.2  0.0 13.6   8.46 
  StdDev   2.3   0.1   0.3   2.5   0.1  1.5 2179.0  802.9 73.1 48.3 73.0   1.39 
-------- ----- ----- ----- ----- ----- ---- ------ ------ ---- ---- ---- ------ 
 Minimum   0.2   0.0   0.1  55.0   0.0  1.0  475.7  243.3  8.0  3.0  7.0   5.74 
 Maximum  43.0   3.5   3.9  99.7   1.5 24.0 35040.9 11026.1 2719.0 1811.0 2697.0  16.97 
-------- ----- ----- ----- ----- ----- ---- ------ ------ ---- ---- ---- ------ 
Summary:
System:   8.58 Watts on average with standard deviation 1.39

Second day:

gered@blarg-laptop ~ $ sudo powerstat -d 180 10 20000
Password: 
Running for 200000.0 seconds (20000 samples at 10.0 second intervals).
Power measurements will start in 180 seconds time.

  Time    User  Nice   Sys  Idle    IO  Run Ctxt/s  IRQ/s Fork Exec Exit  Watts
12:59:11   1.1   0.0   0.6  98.3   0.0    1   2550    922   10    4   20   9.15 

... (omitted for brevity) ...

17:05:51   0.6   0.0   0.3  99.0   0.1    1   1388    501   10    4   11   7.56 
^C-------- ----- ----- ----- ----- ----- ---- ------ ------ ---- ---- ---- ------ 
 Average   4.7   0.0   0.5  94.7   0.0  1.9 3803.3 1453.7 24.4 10.3 24.3   9.11 
 GeoMean   2.5   0.0   0.4  94.4   0.0  0.0 2900.9 1122.6 14.4  0.0 14.8   8.95 
  StdDev   5.8   0.0   0.4   6.1   0.0  2.6 2647.9 1089.7 72.4 74.0 71.7   1.71 
-------- ----- ----- ----- ----- ----- ---- ------ ------ ---- ---- ---- ------ 
 Minimum   0.2   0.0   0.1   6.6   0.0  1.0  611.1  296.0  8.0  3.0  6.0   5.93 
 Maximum  87.1   0.0   7.5  99.6   0.1 30.0 24650.7 12477.2 1628.0 2038.0 1630.0  20.18 
-------- ----- ----- ----- ----- ----- ---- ------ ------ ---- ---- ---- ------ 
Summary:
System:   9.11 Watts on average with standard deviation 1.71 

Basically similar results for both days, between 4 and 5 hours to go from 90% to 10% battery charge.

The reality is that I simply don't need 12+ hours of battery life. And what I get with the Framework laptop is currently more than twice as good as I was getting with my Macbook.

But still, even for someone like me who is coming from a laptop where the best I could expect was 2 to 3 hours (only with extremely light usage, however) and now looking at somewhere around 4 to 6 hours battery life... well, in a post Apple Macbook M1 world I'm still unfortunately left with this "well, darn, my laptop's battery life isn't that great after all" kind of feeling ... even though it is still a step up for me. But this is just because most people's expectations of what the standard should be now has changed. And I'm not saying that's a bad thing.

I think what hurts the Framework laptop the most is Intel. Intel is just too far behind when it comes to power efficiency.

But, there is another problem with the Framework laptop that I don't think can be entirely blamed on Intel, and that is suspend battery life. It's pretty bad. I'm used to being able to close the lid on my Macbook for days and not even think about it. And then come back to it, flip open the lid and not even think about the remaining battery life. Because it would never really be far off what it was when I last used it. The drain during suspend has always just been that good on Apple's laptops. Additionally, Apple also seems to have a really good "suspend-then-hibernate" implementation where after the system has been suspended for a while (not sure how long honestly, I'd guess it is multiple days though) the system automatically hibernates. And you notice this when you come back to it because it takes a little bit longer to resume, but it's never a big deal.

With my Framework laptop, there's no way I can suspend for two days or more before the battery will be drained. It has been demonstrated that certain USB-C port expansions draw more power than others. This is pretty alarming and not something anyone would expect.

To test this a bit on my own, I ran some quick tests to see the difference for myself in my own system. My normal configuration has two USB-C ports and two USB-A ports. As shown in the previous link, the USB-A ports will draw extra power during suspend.

To begin, I removed the two USB-A ports. I just left the ports empty as I do not have any others to use, so only two USB-C ports are connected. No external devices are connected to these USB-C ports however.

gered@blarg-laptop ~ $ sudo tlp-stat -b

... (omitted for brevity) ...

Charge                                                      =   90.8 [%]
Capacity                                                    =   96.8 [%]

gered@blarg-laptop ~ $ date
Fri Jan 20 03:22:41 PM EST 2023

At this point, I put the laptop into suspend and came back after a little less than 8 hours.

gered@blarg-laptop ~ $ sudo tlp-stat -b

... (omitted for brevity) ...

Charge                                                      =   86.0 [%]
Capacity                                                    =   96.8 [%]

gered@blarg-laptop ~ $ date
Fri Jan 20 11:16:46 PM EST 2023

Only 4% battery drain over that time. Even that seems like a lot to me, but I'll admit that I never tested what the exact drain is on my old Macbook Pro. I never had reason to test it.

For the next test, I put the two USB-A ports back in so that the laptop now had both USB-C ports and both USB-A ports plugged in. Again, no external devices are connected into any of these ports.

gered@blarg-laptop ~ $ sudo tlp-stat -b

... (omitted for brevity) ...

Charge                                                      =   90.8 [%]
Capacity                                                    =   99.5 [%]

gered@blarg-laptop ~ $ date
Sat Jan 21 10:06:51 AM EST 2023

I then put the laptop in suspend and came back after about 8 hours and 20 minutes. A little bit longer this time because I forgot about it. Oops.

gered@blarg-laptop ~ $ sudo tlp-stat -b

... (omitted for brevity) ...

Charge                                                      =   73.1 [%]
Capacity                                                    =   99.5 [%]

gered@blarg-laptop ~ $ date
Sat Jan 21 06:27:44 PM EST 2023

This time with the USB-A ports connected we see 17% battery drain. Ouch!

This is a bit of a side rant against systemd, but to make matters worse when I originally got my Framework laptop, there was no working "suspend-then-hibernate" solution. There had previously been one in systemd, however. Apparently "broken" in systemd v252 which is when they fixed what they deemed was incorrect behaviour, the result of which was that the old systemctl suspend-then-hibernate functionality did not work the way that most people would logically expect it to. Some of the discussion that occurs in this Github issue that I found while searching for more information about this is kind of maddening honestly. Some of the comments here seem to indicate that the systemd developers cannot seem to understand what the value of such a feature would be. Really incredibly disappointing.

Thankfully, there was some efforts to fix this merged in this pull request. With this change now merged into systemd, you can regain the old-style of "suspend-then-hibernate" functionality by simply creating a new config file under /etc/systemd/sleep.conf.d/ with something like the following:

[Sleep]
HibernateDelaySec=60min

Assuming you've not made other custom tweaks to your systemd suspend/hibernate settings and you've done other preparations to ensure your system can hibernate in the first place, this should be all that is needed to get systemd suspend-then-hibernate to work. Manually running systemctl suspend-then-hibernate should now suspend your system like normal, and after sitting in an uninterrupted suspended state for the time period specified by HibernateDelaySec, your system will wake itself for just long enough to enter hibernation.

Anyway, with all of this in mind, I've now configured my laptop to suspend and then hibernate after 60 minutes in pretty much every scenario where it suspends (e.g. closing the lid, etc). This helps mitigate the issues with excessive suspend battery drain. Having a longer resume time in such a case isn't too bad. Speedy NVMe storage helps here.

The battery drain issues seem to have been acknowledged by Framework, and they are apparently working on firmware fixes to help address this. So time will tell.

It's also worth mentioning that on my system I have installed and configured TLP which is pretty standard these days for laptops running Linux.

My configuration is mostly default with /etc/tlp.conf only having the following in it:

CPU_ENERGY_PERF_POLICY_ON_AC="balance_performance"
CPU_ENERGY_PERF_POLICY_ON_BAT="power"
PCIE_ASPM_ON_AC="default"
PCIE_ASPM_ON_BAT="powersupersave"
START_CHARGE_THRESH_BAT0=85
STOP_CHARGE_THRESH_BAT0=90

Only the CPU_ENERGY_PERF_POLICY_ON_BAT and PCIE_ASPM_ON_BAT options are changed versus the default settings (of balance_power and default, respectively). As well as the battery charge thresholds, which I've just configured here in a way to match my BIOS settings, as I didn't get the sense that TLP was able to auto-configure this from the BIOS.

Heat

Another thing we can blame on Intel I think. For the most part anyway. This system gets hot quickly. If you put any moderate to significant amount of load on it, the CPU heats up really quickly. And the fan will ramp up quickly too. And the fan is kind of loud. The fan noise doesn't bother me, but I'm always a little wary of excess heat in my electronics.

Intel CPUs have always run pretty hot however. Even my 2014 Macbook Pro suffers from this problem.

Basically (and especially so when running a Gentoo Linux system as I am where compiling packages is common place) stuff like this is not that uncommon a sight for me on my Framework laptop:

I've installed thermald as is a common recommendation in the Framework community for Linux users. This utility helps the system make better choices for CPU performance scaling with respect to the running system's specific hardware so that your CPU won't hit thermal limits quite so fast. As opposed to relying on the more conservative defaults that would otherwise be used by the kernel.

Of note here, is that it still seems to be commonly recommended to install dptfxtract along with thermald. This appears to have not been necessary for a little while now. Intel has archived the dptfxtract utility on Github and the readme notes that thermald since v2.0 now does what the dptfxtract tool does as long as the --adaptive option is used, which appears to be the case at least when run as a systemd service out of the box.

Wobble

Apparently the screen wobble issue was significantly worse with the first generation of the Framework laptop. Since then they started to use better hinges and the wobble is less. But it's still noticeable. I think the hinge that shipped in mine is better than the original hinges were, but there is still another stronger hinge available. If I understand correctly, they don't ship that stronger hinge by default because it prevents one-handed opening of the lid.

Given that other laptop's don't suffer from screen wobble like this while also easily allowing one-handed opening and closing of the lid, I suspect that the hinge isn't really the fundamental issue here. But I'm certainly not an expert.

It's not the end of the world to me as it's only a slight wobble and doesn't cause the lid to shift position through normal use.

Closing Thoughts

Overall, I like this laptop. It's not perfect. It still feels like an "early access product" or something of that sort. And I kind of expected this going into it. But I'm also happy to support a company that I think is doing a very good thing now and into the future instead of just manufacturing even more throw-away "appliances."

I wish some things like battery life were much better, but even at its current level, it is easily meeting my needs.

I don't know if I'd necessarily want to throw out the name "Framework" as a general recommendation to anyone who was looking for a laptop, however. Mostly because I've not yet had to deal with their support yet, so I have no idea how helpful or useless they might be here. And also because they haven't been around for too long yet. I am hopeful that they continue to grow and won't disappear in a few years. Maybe in a few years time when they have a more established reputation having continued to prove their commitment to their current vision, I will feel comfortable with the idea of recommending them to anyone else beyond tech enthusiasts.