Author Archives: Mark

About Mark

Ten years into my journey towards becoming a pro systems programmer, sharing what I learn along the way. Also on Twitter: @offlinemark.

If you're reading this, I'd love to meet you. Please email mark@offlinemark.com and introduce yourself!

I get asked why I’m into C++ and not Rust.

Leave a reply

I get asked why I’m into C++ and not Rust.

Above all, it’s pragmatic. C++ is simply what’s used for the work I aspire to do, and I don’t have time for both.

Beyond that, I still think there’s at least one reason to learn C++ today: out of respect for where it’s gotten us. A lot of lessons to learn from something that powers the world, flaws and all.

And when you do learn Rust, you’ll understand it better. The C++ context will give you a deeper & more intuitive appreciation for why it’s like it is. 

Rust wouldn’t be what it is without C++. 🤝

tweet:

Linux Internals: How /proc/self/mem writes to unwritable memory

2 Replies

Introduction

An obscure quirk of the /proc/*/mem pseudofile is its “punch through” semantics. Writes performed through this file will succeed even if the destination virtual memory is marked unwritable. In fact, this behavior is intentional and actively used by projects such as the Julia JIT compiler and rr debugger.

This behavior raises some questions: Is privileged code subject to virtual memory permissions? In general, to what degree can the hardware inhibit kernel memory access?

By exploring these questions1, this article will shed light on the nuanced relationship between an operating system and the hardware it runs on. We’ll examine the constraints the CPU can impose on the kernel, and how the kernel can bypass these constraints.

Continue reading →

The tradeoffs in using -Weverything

Leave a reply

In addition to the well-known -Wall, clang offers another interesting warning flag: -Weverything. While it sounds like a “strictly better” option (the more warnings, the better?) it’s not.

This topic is already well covered by Arthur O’Dwyer’s blog post and the clang documentation.

Arthur makes a strong case against use of this flag. The clang docs generally agree, though offering a slightly more lenient position:

If you do use -Weverything then we advise that you address all new compiler diagnostics as they get added to Clang, either by fixing everything they find or explicitly disabling that diagnostic with its corresponding Wno- option.

But what I have not seen clearly expressed is how use of -Weverything is a tradeoff.

Continue reading →

Surgical formatting with git-clang-format

Leave a reply

If you’re already a 10x engineer, you probably won’t need this article. But for the rest of us, this is what I wish I knew about clang-format as an inexperienced C++ programmer: how to only format the changes in your pull request.

You may have already heard of clang-format. It auto-formats source files for languages including C and C++. You can aim it at a source file and format the entire thing using clang-format -i file.cpp.

If you’re contributing to a project that is already 100% clang-format clean, then this workflow works fine. But you’ll occasionally encounter a project that is not quite 100% formatted, such as LLVM, osquery, or Electron1.

For these projects, the “format entire files” workflow doesn’t work because you’ll incidentally format parts of the files that are unrelated to your contribution. This will add noise to your diff and make it harder for your reviewers.

In this case, you need a way to surgically format only the lines changed in your contribution. To do this, you can use the clang-format git extension. This article will cover the basics of git-clang-format, including a practical workflow that allows for messy development, and formatting at the end.

Continue reading →

What you should know before taking your gap year (and lessons from mine)

Leave a reply

or alternatively:

I took a year off from my tech career and now I won’t shut up about copywriting.

It was probably going to hurt my career. I was fine with that.

The plan was cliché: quit my job, sell my stuff, spend nine months in Southeast Asia. Produce electronic music, read, and maybe code a little. Then find another tech job and pick up where I left off.

Fast forward twelve months. I haven’t set foot on a plane, I created a software product for DJs, and I’ve developed an obsession with copywriting and digital marketing. What happened?

In this post, I’ll share how, despite all expectations, my gap year catapulted my career into a far more exciting trajectory. I’ll debunk two myths society tells us about gap years and share a framework you can use to generate your own life-changing insights, whether you can take a year or a week off. Lastly, I’ll share advice for taking a gap year of your own.

Continue reading →

How to pick a market that will make you money

Leave a reply

As a founder, picking your market is the most important decision you’ll make. It will impact every aspect of your journey, from product development to sales, and ultimately determine how profitable you’ll be. A good market compensates for poor execution on your part, while even the best execution will struggle with a bad one.

So what goes into a good market?

The key attributes are:

Continue reading →

Open source licensing for supervillains

1 Reply

This post covers my research into open source software licensing and my analysis of real-world open source projects that profit off of open source code via proprietary licenses.

Keep reading and you’ll learn:

  • What the difference between a restrictive and permissive license is
  • What dual licensing is and how you can use it make money off of open source code
  • What CLAs are and the specific clause your CLA needs for use with dual licensing
  • Examples of companies that implement dual licensing and how they do it

And of course: I am not a lawyer and none of this is legal advice.

Let’s talk evil. And by evil, I mean money.

Continue reading →

An actionable framework for yearly goal planning

Leave a reply

Evergreen tweets

Leave a reply

Twitter’s length limit is deceptive. At a glance, it suggests that writing tweets should be easy and quick. This is true for superficial tweets, but does not mean all tweets are written quickly and with little effort.

Twitter is actually a platform for concise writing, and writing concisely is harder than writing verbosely. There are certain tweets I spend a lot of time on and it’s shame to have them get lost in my feed. So I’m storing them here.

Continue reading →