Showing 29 posts
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. 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.