MacBook Pro 16: the good, the bad, and the ugly

-
Late December 2019, I replaced my 2015 model MacBook Pro 13 inch laptop with a 2019 model MacBook Pro 16 inch laptop. The MBP16 laptop provided a long awaited fix to the keyboard Apple broke in 2016. I needed a laptop after 5 years, so I thought this was a good time to hop back on board.

After two months of using it, I am only partially happy with my choice. Let me explain the good, the bad, and the ugly parts.

Good

Big screen: In terms of screen real estate the MBP16 is a big upgrade over my old MBP13. This was very similar to going to a big-screen iPhone: initially the big screen iPhone feels outrageously huge at your hand, but after a week, you look at your old small-screen iPhone surprised how you were able to use that stupidly tiny child-toy. After a week of MBP16, trying to use the MBP13 felt exactly that way.

Keyboard: The keyboard is good. I didn't like the keyboard too much in the beginning because I was switching from 2015 MBP13 which had a good keyboard. But after a couple days of using MBP16, I concluded that its keyboard is better than my old MBP13 keyboard. The keyboard feels more sturdy and solid than the MBP13 keyboard.

Speakers: Oh my... The speakers in MBP16 are amazing, they feel like surround sound. Deep bass, and great experience. (If you are in an open office environment, you won't get to enjoy this feature much.)

Bad 

Touchbar: The touchbar is a gimmick. I don't really have any good use for it. I would be happy to trade the touchbar with physical Function keys any time. I have several assigned Emacs macros for the Function keys. Since the function keys are displayed at the touchbar, there is no haptic feedback when you press on them. As a result I don't realize it when my finger remains on the key more than the normal time, and this causes the macro to execute repeatedly, which is very annoying. Well, you know, at least the escape key is a physical key, so we have that going for us. (By the way, this was one of the big selling point for MBP16! "We give you back the Escape key, worship us again!")

Build quality: I had to get my first MBP16 replaced after the first week due to issues (see the ugly section below for the issues). My replacement laptop arrived, and it had uneven footing. I patched the problem by adding stickers to the foot which was a couple mms shorter than the others. I didn't want to start another return to Apple. As another issue with build quality, last week, I discovered a ding on the aluminum back cover of the screen. I never got a ding in the back cover of my old MBP13 in 5 years, and I have no idea how this one occurred.

Ugly

External display problem:  Initially, I had only one power adapter for my MBP16, which I kept at home. MBP16 is advertised as having 11 hours battery life, so I thought I could be OK without a power adapter at my office for a while. But I  was flabbergasted when I saw that the battery drained within 3 hours! I thought there was something very wrong with the battery and I started a return/replacement. It took me another week to realize that my problem was the external display; when I used the MBP16 without the external display (which I don't do often), the battery indeed lasted for 11 hours. I was unable to make the connection before that because this never happened with my MBP13: my MBP13 would not have any noticeable increase in battery drainage even when used with the external display.

The reason this happens is because MBP16 has dual graphics: Intel UHD Graphics 630 1536 MB, and AMD Radeon Pro 5300M 4 GB. The more powerful AMD Radeon Pro kicks in when an external display is connected, and drains the battery quickly. It also heats up the laptop; the part above the touchbar gets very hot and the fans start to scream when you are using an external display. Om Malik recently reported that MBP16 has a fan problem. No it has an external display problem. I hope Apple can create a software patch to alleviate the problem.

I carried on with the return/replacement, because the first MBP16 had random crush/restart issue. It would have random restarts almost every night and a couple times while I was using it, with some weird kernel panic message (some involving the GPU/graphics card). The replacement MBP16 indeed solved the crash/restart problem. But it still suffers from the external display battery drainage problem, and I ended up buying another power adapter for my office. I also make sure I go to my lectures with full battery, because I need to hook up to the external display/projector.

Even with the adaptor

Conclusion

The MacBook Pro went from a product I adored to a product I tolerate due to lack of options. I am still partially happy with my choice, because the other laptops are not any better, and I am so used to Macs after 15 years of using them.

The way Moore's law seem to be doing nothing for laptops is amazing! Objectively they should be a couple order of magnitude better than laptops from 20 years ago. But I feel like my first laptop, the Thinkpad laptop I bought in 2001 with its FreeBSD+XFCE setup, has been the laptop that felt the fastest. Yes, the switch to SSDs provided a big boost around 2012, but excepting that I don't feel like I see a 20 years worth improvement over my 2001 Thinkpad.

This laptop should take me for another 5 years (let's cross our fingers). I hope 2025 will finally be the year of Linux desktop. I want to switch to a Linux (or FreeBSD) laptop, and I hope I won't need to allocate 1 week from my schedule to get it setup.

Comments

Bart van Deenen said…
I use a Macbook Pro at work at the moment (provided for and managed by the company).

Whenever I get back at home, and work on my Dell Latitude running Void Linux, I can breathe a sigh of relief. The keyboard is better, it feels faster, it boots 10 times faster, and I can do everything I want with it. As far as a no hassles setup, I'd say the Void Linux laptop is less hassle than a Mac (at least it's a rolling release, that will never force a major OS upgrade down your throat).

Also, the customizability of the Linux machine leaves the Mac in the dust (I hate the stupid Mac window manager, and that you'd pretty much have to buy extensions to provide things that Xfce provides out of the box like corner snapping and such).

Considering the price difference, there really is no contest between the two, the Mac is 4 times more expensive.

February 21, 2020 at 6:08 AM
Roland Smith said…
I've been using FreeBSD on laptops and workstations for years now.

Currently, if you get a laptop with Intel CPU and built-in graphics, it should work out-of-the-box without problems. Generally I don't buy the latest and greatest. Last year I bought a Kaby Lake based laptop from BTO (re-branded Clevo). It works fine with FreeBSD 12.1 and performs well.

Configuring a new laptop takes me around two days. Mostly because I like to build my ports with non-default options.

Generally I follow FreeBSD-STABLE and update it whenever I see the need to do so.
March 7, 2020 at 7:30 AM
Post a Comment

Popular posts from this blog

Hints for Distributed Systems Design

-
This is with apologies to Butler Lampson, who published the " Hints for computer system design " paper 40 years ago in SOSP'83. I don't claim to match that work of course. I just thought I could draft this post to organize my thinking about designing distributed systems and get feedback from others. I start with the same  disclaimer Lampson gave. These hints are not novel, not foolproof recipes, not laws of design, not precisely formulated, and not always appropriate. They are just hints.  They are context dependent, and some of them may be controversial. That being said, I have seen these hints successfully applied in distributed systems design throughout my 25 years in the field, starting from the theory of distributed systems (98-01), immersing into the practice of wireless sensor networks (01-11), and working on cloud computing systems both in the academia and industry ever since. These heuristic principles have been applied knowingly or unknowingly and has proven
Read more >>

Learning about distributed systems: where to start?

-
This is definitely not a "learn distributed systems in 21 days" post. I recommend a principled, from the foundations-up, studying of distributed systems, which will take a good three months in the first pass, and many more months to build competence after that. If you are practical and coding oriented you may not like my advice much. You may object saying, "Shouldn't I learn distributed systems with coding and hands on? Why can I not get started by deploying a Hadoop cluster, or studying the Raft code." I think that is the wrong way to go about learning distributed systems, because seeing similar code and programming language constructs will make you think this is familiar territory, and will give you a false sense of security. But, nothing can be further from the truth. Distributed systems need radically different software than centralized systems do.  --A. Tannenbaum This quotation is literally the first sentence in my distributed systems syllabus. Inst
Read more >>

Making database systems usable

-
Image
C. J. Date's Sigmod 1983 keynote, "Database Usability", was prescient. Usability is the most important thing to the customers. They care less about impressive benchmarks or clever algorithms, and more about whether they can operate and use a database efficiently to query, update, analyze, and persist their data with minimal headache. (BTW, does anyone have a link to the contents of this Sigmod'83 talk? There is no transcript around, except for this short abstract .) The paper we cover today is from Sigmod 2007. It takes on the database usability problem raised in that 1983 keynote head-on, and calls out that the king is still naked.  Let's give some context for the year 2007. Yes, XML format was still popular then. The use-case in the paper is XQuery. The paper does not contain any  reference to json. MongoDB would be released in 2009 with the document model; and that seems to be great timing for some of the usability pains mentioned in the paper! Web 2.0 was in
Read more >>

Looming Liability Machines (LLMs)

-
As part of our zoom reading group ( wow, 4.5 years old now ), we discussed a paper that uses LLMs for automatic root cause analysis (RCA) for cloud incidents. This was a pretty straightforward application of LLMs. The proposed system employs an LLM to match incoming incidents to incident handlers based on their alert types, predicts the incident's root cause category, and provides an explanatory narrative. The only customization is through prompt-engineering. Since this is a custom domain, I think a more principled and custom-designed  machine learning system would be more appropriate rather than adopting LLMs. Anyways, the use of LLMs for RCAs spooked me vicerally. I couldn't find the exact words during the paper discussion, but I can articulate this better now. Let me explain. RCA is serious business Root cause analysis (RCA) is the process of identifying the underlying causes of a problem/incident, rather than just addressing its symptoms. One RCA heuristic is asking 5 Why&#
Read more >>

Foundational distributed systems papers

-
I talked about the importance of reading foundational papers last week. To followup, here is my compilation of foundational papers in the distributed systems area. (I focused on the core distributed systems area, and did not cover networking, security, distributed ledgers, verification work etc. I even left out distributed transactions, I hope to cover them at a later date.)  I classified the papers by subject, and listed them in chronological order. I also listed expository papers and blog posts at the end of each section. Time and State in Distributed Systems Time, Clocks, and the Ordering of Events in a Distributed System. Leslie Lamport, Commn. of the ACM,  1978. Distributed Snapshots: Determining Global States of a Distributed System. K. Mani Chandy Leslie Lamport, ACM Transactions on Computer Systems, 1985. Virtual Time and Global States of Distributed Systems.  Mattern, F. 1988. Practical uses of synchronized clocks in distributed systems. B. Liskov, 1991. Expository papers
Read more >>

Advice to the young

-
Image
I notice I haven't written any advice posts recently. Here is a collection of my advice posts pre 2020. I've been feeling all this elderly wisdom pent up in me, ready to pour at any moment. So here it goes. Get ready to quench your thirst from my fount of wisdom. No man, think for yourself, only get what works for you. It is called foundations, not theory Foundations of computer science (or rather any field of study) are the most important topics you can learn. These lay down the frame of thinking/perspective for that area of study. Yet, I am saddened to hear these called as "theory", and labeled as "unpractical". This couldn't be farther from the truth. Take a look at how I recommend studying distributed systems . Don't you dare call this "theory" and "unpractical". This lays the bedrock that you build your practice on. Don't skimp on the foundations. Don't build your home on quicksand. Keep your hands dirty, your mind cl
Read more >>

Linearizability: A Correctness Condition for Concurrent Objects

-
Image
This paper is from Herlihy and Wing appeared in ACM Transactions on Programming Languages and Systems 1990. This is the canonical reference for the linearizability definition. I had not read this paper in detail before, so I thought it would be good to go to the source to see if there are additional delightful surprises in the original text. Hence, this post. I will dive into a technical analysis of the paper first, and then discuss some of my takes toward the end. I had written an accessible explanation of linearizability earlier; you may want to read that first. I will assume an understanding of linearizability to keep this review at reasonable length. Introduction I love how the old papers just barge in with the model, without bothered by pleasantries such as motivation of the problem. These are the first two sentences of the introduction. "A concurrent system consists of a collection of sequential processes that communicate through shared typed objects . This model encompass
Read more >>

Scalable OLTP in the Cloud: What’s the BIG DEAL?

-
Image
This paper is from Pat Helland, the apostate philosopher of database systems, overall a superb person, and a good friend of mine. The paper appeared this week at CIDR'24. (Check out the program for other interesting papers). The motivating question behind this work is: " What are the asymptotic limits to scale for cloud OLTP (OnLine Transaction Processing) systems? " Pat says that the CIDR 2023 paper "Is Scalable OLTP in the Cloud a Solved Problem?" prompted this question.  The answer to the question? Pat says that the answer lies in the joint responsibility of database and the application. If you know of Pat's work, which I have summarized several in this blog , you would know that Pat has been advocating along these lines before. But this paper provides a very crisp, specific, concrete answer. Read on for my summary of the paper. Disclaimer: This is a wisdom and technical information/detail packed 13-page paper, so I will try my best to summarize the sa
Read more >>

Understanding the Performance Implications of Storage-Disaggregated Databases

-
Image
Storage-compute disaggregation in databases has emerged as a pivotal architecture in cloud environments, as evidenced by Amazon ( Aurora ), Microsoft ( Socrates ), Google (AlloyDB), Alibaba ( PolarDB ), and Huawei (Taurus). This approach decouples compute from storage, allowing for independent and elastic scaling of compute and storage resources. It provides fault-tolerance at the storage level. You can then share the storage for other services, such as adding read-only replicas for the databases. You can even use the storage level for easier sharding of your database. Finally, you can also use this for exporting a changelog asynchronously to feed into peripheral cloud services, such as analytics. Disaggregated architecture was the topic of Sigmod 23 panel . I think this quote summarizes the industry's thinking on the topic. "Disaggregated architecture is here, and is not going anywhere. In a disaggregated architecture, storage is fungible, and computing scales independently.
Read more >>

Designing Data Intensive Applications (DDIA) Book

-
Image
We started reading this book as part of Alex Petrov's book club . We just got started, so you can join us, by joining the discord channel above. We meet Wednesday's 11am Eastern Time.  Previously we had read transaction processing book by Grey and Reuters. This page links to my summaries of that book. Chp 1. Reliable, Scalable, and Maintainable Applications I love the diagrams opening each chapter. Beautiful! The first chapter consists of warm up stuff. It talks about the definitions of reliabilty, scalability, and maintainability. It is still engaging, because  it is written with an educator and technical blogger voice, rather than a dry academic voice. This book came out on 2017. Martin is working on the new version. So if you have comments for things to focus on for the new version, it would be helpful to collect them in a document and email it to Martin. For example, I am curious about how the below paragraph from the Preface will get revised with 8 more years of hindsight:
Read more >>