Showing 43 posts
Well, that was unexpected. I recorded a couple of crappy videos in 5 minutes, posted them on a Twitter thread, and went viral with 8.8K likes at this point. I really could not have predicted that, given that I’ve been posting what-I-believe-is interesting content for years and… nothing, almost-zero interest. Now that things have cooled down, it’s time to stir the pot and elaborate on those thoughts a bit more rationally. To summarize, the Twitter thread shows two videos: one of an old computer running Windows NT 3.51 and one of a new computer running Windows 11. In each video, I opened and closed a command prompt, File Explorer, Notepad, and Paint. You can clearly see how apps on the old computer open up instantly whereas apps on the new computer show significant lag as they load. I questioned how computers are actually getting better when trivial things like this have regressed. And boom, the likes and reshares started coming in. Obviously some people had issues with my claims, but there seems to be an overwhelming majority of people that agree we have a problem. To open up, I’ll stand my ground: latency in modern computer interfaces, with modern OSes and modern applications, is terrible and getting worse. This applies to smartphones as well. At the same time, while UIs were much more responsible on computers of the past, those computers were also awful in many ways: new systems have changed our lives substantially. So, what gives?
After three months of early-morning hacking, I’m pleased to announce that EndBASIC 0.10 is now available—right on time for some holiday-time experimentation! This release marks a huge milestone because it makes the language usable for real-world development. You see, when I started this project over two years ago, I wrote a rudimentary interpreter for something that resembled BASIC and then launched EndBASIC 0.1. Since then, I have been piling onto those insufficient foundations by adding flashy features such as a web interface, a cloud file sharing service, and a hybrid text/graphics console.
After two years, it’s time for a change: I left Microsoft last week and I’m starting at Snowflake today. Read on for details on my stint in Azure Storage, why I ended up looking for a new role, and how I landed at this new company.
Rust is infamous for having a steep learning curve. The borrow checker, preferred idioms and design patterns, the meaning of core traits… these are all things one must learn before being proficient with the language and able to write code with ease. So, yes, Rust is hard, but does it matter in practical terms? Can we expect large-ish teams to succeed when adopting the language? I’d like to think that it does not matter much and that some initial difficulties in bringing people up to speed can pay off in the medium term.
Dependency injection is one of my favorite design patterns to develop highly-testable and modular code. Unfortunately, applying this pattern by taking Rust traits as arguments to public functions has unintended consequences on the visibility of private symbols. If you are not careful, most of your crate-internal APIs might need to become public just because you needed to parameterize a function with a trait. Let’s look at why this happens and what we can do about it.
2022-03-07: Introduction 2022-03-08: Keyboard shortcuts 2022-03-09: Input methods 2022-03-10: Look'n'feel 2022-03-11: Window switching 2022-03-12: PowerToys 2022-03-13: Miscellaneous tools 2022-03-14: Development experience 2022-03-15: PowerShell 2022-03-16: Networked file systems 2022-03-17: System debugging 2022-03-18: Software installation 2022-03-19: Finale A bit over a week ago, I narrated my decades-long love and hate relationship with Windows. Today, it’s time to start covering my impressions of this platform after spending a year on it as my primary OS. This is noteworthy because I had been a Unix-only person for about 25 years and spent the last 15 on macOS alone. Switching to Windows 10 and 11 has been quite a change and… for the most part, a positive one. I like what I’ve seen.
A good philosophy to live by at work is to “always be quitting”. No, don’t be constantly thinking of leaving your job 😱. But act as if you might leave on short notice 😎. Counterintuitively, this will make you a better engineer and open up growth opportunities. A thread 👇.
Monorepos are an interesting beast. If mended properly, they enable a level of uniformity and code quality that is hard to achieve otherwise. If left unattended, however, they become unmanageable monsters of tangled dependencies, slow builds, and frustrating developer experiences. Whether you have a good or bad experience directly depends on the level of engineering support behind the monorepo. Simply put, monorepos require dedicated teams and tools to run nicely. In this post, I will look at how almost-perfect caching plays a key role in keeping build times manageable under such an environment.
During my 11 years at Google, I can confidently count the number of times I had to do a “clean build” with one hand: their build system is so robust that incremental builds always work. Phrases like “clean everything and try building from scratch” are unheard of. So… you can color me skeptical when someone says that incremental build problems are due to bugs in the build files and not due to a suboptimal build system. The answer lies in having a robust build system, and in this post I’ll examine the common causes behind incremental build breakages, what the build system can do to avoid them, and how Bazel accomplishes most of them.
The most notable feature in EndBASIC 0.3 is its new full-screen console-based text editor. In this post, I describe why it is important and useful to unit-test a console app like this, and I will dive into how to implement unit tests that catch regressions and inefficiencies. Code samples are in Rust, but the concepts presented here are applicable to any language with minimal data abstraction facilities.
If you have followed Windows 10 at all during the last few years, you know that the Windows Subsystem for Linux, or WSL for short, is the hot topic among developers. You can finally run your Linux tooling on Windows as a first class citizen, which means you no longer have to learn PowerShell or, god forbid, suffer through the ancient CMD.EXE console. Unfortunately, not everything is as rosy as it sounds.
After a little over 11 years, it’s time for a much longed change: I’m leaving Google and I’m joining Microsoft as a Principal Software Engineer for Azure. These job changes are effective as of this week, but my family and I already moved from New York City to Redmond, WA about three weeks ago. Read on for a recap on my tenure at Google, the whys behind my departure, and how I ended up choosing the position in Microsoft Azure after mulling over offers from Facebook, Twitter, and Microsoft.
Have you ever wondered why an increasing number of programs are configured by placing small files in .d directories instead of by just editing a single file? Have you ever wondered why these .d directories seem to proliferate in Linux installations? Read on to understand what these are and why they are useful.
Introducing EndBASIC, a new interpreter for a BASIC-like language that is inspired by Amstrad’s Locomotive BASIC 1.1 and Microsoft’s QuickBASIC 4.5. Like the former, EndBASIC intends to provide an interactive environment that seamlessly merges coding with immediate visual feedback. Like the latter, EndBASIC offers higher-level programming constructs and strong typing. The main idea behind EndBASIC is to provide a playground for learning the foundations of programming in a simplified environment.
You probably know that software rewrites, while very tempting, are expensive and can be the mistake that kills a project or a company. Yet they are routinely proposed as the solution to all problems. Is there anything you can do to minimize the risk? In this post, I propose that you actively improve the old system to ensure the new system cannot make progress in a haphazard way. This forces the new system to be designed in such a way that delivers breakthrough improvements and not just incremental improvements.
Over the summer, I prototyped a bunch of web apps whose ideas had been floating in my mind for a long time. I spent some time reading through REST API documentation pages and, as part of these exercises, implemented sample RESTful web services in both Go and Rust. (Just for context, the last time I wrote a web app was in high school… and it involved PHP, MySQL, and I think IE6?
Since the publication of Bazel a few years ago, users have reported (and I myself have experienced) general slowdowns when Bazel is running on Macs: things like the window manager stutter and others like the web browser cannot load new pages. Similarly, after the introduction of the dynamic spawn scheduler, some users reported slower builds than pure remote or pure local builds, which made no sense. All along we guessed that these problems were caused by Bazel’s abuse of system threads, as it used to spawn 200 runnable threads during analysis and used to run 200 concurrent compiler subprocesses.
I am pleased to announce that the first release of sandboxfs, 0.1.0, is finally here! You can download the sources and prebuilt binaries from the 0.1.0 release page and you can read the installation instructions for more details. The journey to this first release has been a long one. sandboxfs was first conceived over two years ago, was first announced in August 2017, showed its first promising results in April 2018, and has been undergoing a rewrite from Go to Rust.
There is no good answer to this question: people tend to put Go and Rust in the same bucket because they were released at around the same time, because Rust’s release felt like a response to Go’s, and because they are marketed to similar audiences. They are, however, vastly different. So let’s give in and compare them anyway.
This post is a short, generalized summary of the preceeding two. I believe those two posts put readers off due to their massive length and the fact that they were seemingly tied to Bazel and Java, thus failing to communicate the larger point I wanted to make. Let’s try to distill their key points here in a language- and project-agnostic manner.
Many programming guides recommend to begin scripts with the #! /usr/bin/env shebang in order to to automatically locate the necessary interpreter. For example, for a Python script you would use #! /usr/bin/env python, and then the saying goes, the script would “just work” on any machine with Python installed. The reason for this recommendation is that /usr/bin/env python will search the PATH for a program called python and execute the first one found… and that usually works fine on one’s own machine.
I confess I am late to the game: the Go programming language came out in 2009 and I had not had the chance to go all in for a real project until two weeks ago. Here is a summary of my experience. Spoiler alert: I’m truly pleased. The project What I set out to build is a read-only caching file system to try to solve the problems I presented in my previous analysis of large builds on SSHFS.
A commonly held axiom in the BSD community is that the C compiler belongs in the base system. “This is how things have been since the beginning of time and they define the way BSD systems are”, the proposition goes. But why is that? What makes “having a compiler in base” a BSD system? Why is the compiler a necessary part of the base system? Hold on, is it? Could we take it out?
As I spend September in Seoul and attend an intensive Korean language course, my story with English comes to mind. This is a story I have told a bunch of times to friends and coworkers and it’s time to write it down for posterity’s sake. In the title of this post is a verbatim quote of something I have been told many times throughout the years: Your English is pretty good!
How would you best organize your work environment for maximum productivity if you were tasked to develop a type of application you had never developed before? Wouldn’t it be nice if you could witness how an experienced developer manages the tools of the craft so that you could draw ideas and incorporate them into your own workflow? This post aims to answer the above for the type of work I do by sharing how my workflow looks like. I want to compel you to share your own story in the comments section, and by doing so, create a collection of stories so that others can benefit from them.
You are the developer in charge to resolve a problem and have prepared a changelist to fix the bug. You need the changelist to be reviewed by someone else before checkin. Your changelist is an ugly hack. What kind of response are you gonna get from your reviewer? Well as with everything: it depends! (Cover image courtesy of http://www.startupstockphotos.com/.) If you have: clearly stated upfront that the changelist is a hack, explained how it is a hack, justified that the hack is the right thing to do at this moment, and outlined what the real solution to get rid of the hack would be then your reviewer will most likely just accept the change without fuss (!
Do you have any idea which online services and stores have you given your email address to? Are you able to quantify the effort it would take to fully migrate to a different email account if you ever wanted to? (Cover image courtesy of http://www.startupstockphotos.com/) Three years ago, I was not able to answer these two simple questions when I decided to move my email account to our new family-owned domain.
Mission: Site Reliability Engineer for the Storage Infrastructure at Google D-Day: May 25th, 2009 Location: Dublin, Ireland Duration: Unspecified Six years have passed. Six years since I dropped out of a Ph.D. program, left home, and took a plane to Dublin, Ireland, to start my work life adventure by joining Google. Two years later, I moved to New York City and I am still here without any specific plans to leave.
In search for a new home to personal essays. 11 years. Next month will mark 11 years since the creation of The Julipedia, the personal blog that got me started into this writing journey. 11 years that have brought 690 posts (yeah, yeah, not that many for such a long time). And after all this time, it finally hit me: personal blogs have lost their original appeal. It is time for a change.
This is a rare post because I don’t usually talk about Google stuff here, and this post is about Bazel: a tool recently published by Google. Why? Because I love its internal counterpart, Blaze, and believe that Bazel has the potential to be one of the best build tools if it is not already. However, Bazel currently has some shortcomings to cater to a certain kind of important projects in the open source ecosystem: the projects that form the foundation of open source operating systems.
iGTD, Things, Org mode, OmniFocus, Google Tasks, Trello, Google Keep… All of them. All of them I have tried over the last few years and all of them have failed me in some way — or, rather, I have failed to adjust to their idiosyncrasies. Part of it is because the overwhelming feeling that builds up after days of continuous use due to how easy it is to end up with never-ending piles of open tasks.
One of the things that often shocks new engineers at Google is the fact that every change to the source tree must be reviewed before commit. It is hard to internalize such a workflow if you have never been exposed to it, but given enough time —O(weeks) is my estimation—, the formal pre-commit code review process becomes a habit and, soon after, something you take for granted. To me, code reviews have become invaluable and, actually, I feel “naked” when I work on open source projects where this process is not standard practice.
Are you looking for a method to merge multiple Git repositories into a single one? If so, you have reached the right tutorial! Please bear with me for a second while I provide you with background information and introduce the subject of our experiments. We’ll get to the actual procedure soon and you will be able to apply it to any repository of your choice. In the Kyua project, and with the introduction of the kyua-atf-compat component in the Summer of 2012, I decided to create independent Git repositories for each component.
I joined the FreeBSD committer ranks a couple of months ago with the intention to equip FreeBSD with an out-of-the-box test suite and with a testing infrastructure. The time until now has been quite fruitful and I have been rushing to get something ready for you before the year end. With that, I am very pleased to announce that the first mockup of the FreeBSD testing cluster is up and running!
A few months ago I bought an old PowerMac G5 off of Craigslist and since then I have been experimenting with various operating systems and configurations. Before I tell you more about these, let me briefly explain why I got such a machine. <img src="/images/2013-07-15-Power_Mac_G5_open.jpg" alt=“Power Mac G5 open case” class=“float-right” width=“250px” /> I had always wanted one of these beasts. They look gorgeous (to me) and, to convince myself to get it, I thought that I would play with the PPC64 architecture.
The decision to not renew my NetBSD board membership was bittersweet. Let me put aside the Readability series posts for a moment while I recap how the two years serving the NetBSD Board of Directors have been. My term just finished a couple of weeks ago, so it is better to post this while it is still relevant. First, let me backtrack a little bit. A couple of years ago, I was nominated to serve the NetBSD Board of Directors.
This article first appeared on this date in O’Reilly’s ONLamp.com online publication. The content was deleted sometime in 2019 but I was lucky enough to find a copy in the WayBack Machine. I reformatted the text to fit the style of this site and fixed broken links, but otherwise the content is a verbatim reproduction of what was originally published. The i386 architecture is full of cruft required to maintain compatibility with old machines that go back as far as the 8086 series.
This article first appeared on this date in O’Reilly’s ONLamp.com online publication. The content was deleted sometime in 2019 but I was lucky enough to find a copy in the WayBack Machine. I reformatted the text to fit the style of this site and fixed broken links, but otherwise the content is a verbatim reproduction of what was originally published. C++, with its complex and complete syntax, is a very versatile language.
This article first appeared on this date in O’Reilly’s ONLamp.com online publication. The content was deleted sometime in 2019 but I was lucky enough to find a copy in the WayBack Machine. I reformatted the text to fit the style of this site and fixed broken links, but otherwise the content is a verbatim reproduction of what was originally published. The Apache HTTP Server is the most popular web server due to its functionality, stability, and maturity.
This article first appeared on this date in O’Reilly’s ONLamp.com online publication. The content was deleted sometime in 2019 but I was lucky enough to find a copy in the WayBack Machine. I reformatted the text to fit the style of this site and fixed broken links, but otherwise the content is a verbatim reproduction of what was originally published. My previous article, Making Packager-Friendly Software (part 1), explains why software packaging is sometimes problematic due to real problems in the mainstream sources.
This article first appeared on this date in O’Reilly’s ONLamp.com online publication. The content was deleted sometime in 2019 but I was lucky enough to find a copy in the WayBack Machine. I reformatted the text to fit the style of this site and fixed broken links, but otherwise the content is a verbatim reproduction of what was originally published. A package maintainer, or packager, is a person who creates packages for software projects.