Arjen Wiersma

Let me tell you how it was to ship a product out to half a million people back in 1999. But before I do that, let me tell you why. Today I talked to one of my students and he mentioned that he was very nervous about a change he was making. He was afraid it would break things and that he would spend the afternoon working through his CI/CD pipeline to resolve issues.

Well, back in 1999 I worked on a project. Together with some friends we were building cool software in Borland Delphi and life was good. One of the things that we had built was a nifty dialler application that you could run on Windows. It would dial into your ISP and it made the entire process a lot easier and it made all the dealings with modems and telephone lines so much simpler. Why would we make such a thing? It was actually a commission for one of the earlier internet providers in The Netherlands. It was well received and we made our first big bucks. It was awesome.

After finishing the project I received a call. There was a secret project in the parent company and they needed the software as well. The project turned out to be the creation of a free internet provider. The provider was Freeler. The term free meant you only paid for your telephone line, but not for the service itself. It was a cool and radical idea and the parent company gave the project group 1 month to put everything into place and market it. In modern times that would be 1 sprint.

Needless to say it was a pressure cooker. In hindsight I did not really understand many of things going on, I was just focused on modifying my dialler application to do the job that was asked. The idea was to have a CD ROM ready just before launch time. The CD ROM would then be placed at gas stations and other high traffic areas. It had to work flawlessly. The thing with CD ROMs is that you can't send a patch if something is wrong.

As I was just out of my teen years it was all quite hectic and I had never released software on this scale. So I made my changes to the application, but how do you make sure it is correct? It worked on my computer, but how do you test something like this? Well, first you need to make your CD ROM. So we built an image and sent it to the pressing company, we received a box a few hundred testers the next day. So, time to call all our family members? Fun fact, thanks to people of the internet archive you can still download the CD ROM image from them.

{{< figure src=“/ox-hugo/freeler.png” alt=“the Freeler CD ROM” width=“300” >}}

After some calls and research my technical partner on the project found a laboratory that actually specialized in testing CD ROMs. It was one of the coolest things ever; they take your CD ROM and feed it to a robotized setup. In this laboratory they had hundreds of machines from various manufacturers running various versions of the Windows operating system. It was pure magic to behold.

We spent several days at the laboratory getting results. Some machines did not auto start the software, others ran into issues setting up the connections. It was an effort, but at the end of the day I fixed all the issues and a master cd was made. This is basically the template from which all the copies are created.

So, now we have some tested software and a distribution medium that will work with the target audience. We are finished right? Well, no. As people use the CD ROMs they will have questions. Some people will never have dialled into the internet before, some people might not even have a modem (no, that is not a joke). So to ensure their questions are answered a call center is needed. I don't remember how big the call center was, but I do remember it was in the center of Groningen.

Given the time crunch, the deadline was only in a few days, these operators needed to be trained. They needed to be trained in working with the dialler application. So I was sent to Groningen to work with the call center. Imagine the sight; you just created an application, went to a laboratory to test it, then created a bunch (a million-ish) CD ROMs and then you wait for people to call with issues. The first time the phone rings you heart drops. “Did it not work?”, “Did I miss something?”.... it is not like you can go around people's house to fix the issues. Patching it is not possible, since they use the application to get onto the internet.

Luckily for me the software worked quite nicely. Freeler grew to 350.000 members. But to release this simple piece of software I spent weeks working through many painstaking processes.

So why do I tell this story? Well... having the luxury of CI/CD, instant feedback and the ability to patch things the same minute/hour/day should be the greatest good in the world. Be fearless, merge your changes, fix your issues, deploy without anxiety.... you will never have to see a robot feed a CD ROM to a computer in order to find out if you code works.

#development #writing

I use lsp-mode quite extensively. I switched from eglot when I started using LSP more. The beautify of lsp-mode is that it will automatically install language servers as you need them. It also integrates excellently with dap-mode to enable debugging sessions. So, I switched to it, turned off all the information overload and I am quite happy.

One thing I do extensively is that I use LaTeX to make my slides for college class slides and class assignments. That means I have hundreds of directories with presentations, assignments and other documents. Each time I enter a directory for a class it will spawn an LSP session for that set of LaTeX files.

Then there are the assignments that are handed in. Mostly Java and JavaScript types of projects that I grade. This is wonderful work and I am glad I can do it within Emacs, instead of having to spawn up some IDE to just browse code structures.

The downside to all this is that my lsp-describe-session list becomes huge. At one point I had over 100 sessions stored in it, most of them fleeting due to work I graded at the end of a semester. Luckily you can just clean those folders up by calling lsp-workspace-folders-remove. As an interactive function you can call it, select the folder to remove and be done with it.

Needless to say that I did not feel like doing that manually for 100+ folders. So I created a small snippet of elisp to automate this. It is listed below, feel free to copy it. It will clean out all your LSP folders, so you will need to create the ones you need again after using it, but lsp-mode will do just that for you.

(defun aw/cleanup-lsp ()
  "Remove all the workspace folders from LSP"
  (interactive)
  (let ((folders (lsp-session-folders (lsp-session))))
    (while folders
      (lsp-workspace-folders-remove (car folders))
      (setq folders (cdr folders)))))

As the world is processing the Twitter deal the open source project Mastodon is gaining a lot of traction. The instance that I am on, fosstodon, is run by a small team and is fully funded by donations.

Now this may sound somewhat strange; as the twitterverse is blowing up about $8/month for a blue checkmark I would argue that the $8 is better spent supporting open source projects. As developers, security people, and users we rely on a lot of free time and effort from open source contributors.

Sustainable open source {#sustainable-open-source}

This idea of sustainable open source is not new. On Github you can already donate to your favorite projects and many people accept money through patreon or Liberapay. This is a good step towards sustainability. To illustrate what could go wrong if we don't move more into this direction we should look at the case of Marak Squiress.

You might've heard about color.js and faker.js. The latter was used to generate fake data for testing forms in web applications and such. Both projects were used by thousands of other projects. Most developers did not even notice this dependency in their project as it would be deep into the dependency tree.

One day Marak got fed up. He was tired of working on his projects and seeing companies use his projects without giving back. So he pleaded with the outside world to no avail. Sadly it seems he totally burned out and removed his projects from various repositories. Needless to say, stuff started to break. As the NPM ecosystem is not geared towards reproducability (and general usability) a missing package will only be followed with absolute failure.

The detailed story of Marak and his decision is quite the read, I highly recommend going through it and reflecting on what it would mean for your own projects.

Dependencies {#dependencies}

The fragility of dependencies is not new. In an XKCD comic it was beautifully illustrated:

{{< figure src=“/ox-hugo/dependency.png” >}}

There are countless examples where this goes wrong. Just in the NPM space it is quite easy to find examples where funding would've helped. Lets take a look at some supply chain attacks where a better funded developer might've taken the time to actually setup better security for themselves.

In November of 2018 a malicious package was added as a dependency to version 3.3.6 of the popular package event-stream by a new maintainer. The malicious package, called flatmap-stream, contained an encrypted payload that stole bitcoins from certain applications. Read the NPM Blog for an incident report.

In October of 2021 the NPM account for the UA-Parser-JS library was hijacked, to infect dependent systems with cryptominers and password-stealing trojans in a supply-chain attack. There is a Detailed story that goes into all the steps involved.

In July of 2018 the credentials of a maintainer on NPM were compromised resulting in a malicious release of eslint-scope, version 3.7.2. The malicious code copied the npm credentials of the machine running eslint-scope and uploaded them to the attacker. There is a good blog post by the ESLint team.

Although better funding does not mean better security posture, it would mean that developers get more time to spend on their projects. More time generally results in better choices and hopefully also security choices.

OpenSSL {#openssl}

Outside the NPM realm you can also throw a stone and find an interesting story. Lets take a look at OpenSSL on November 1st of 2022. The release a critical patch for a vulnerability. Instead of it being something that was broken when security was not on the forefront this time it was a vulnerability in new code. Code that was just recently added, knowing how important OpenSSL is in the ecosystem. Sadly it was not tested enough. The code dealt with the parsing of punycode urls in email addresses. It resulted in a trivial buffer overflow; using <= instead of <. Read more about it in their blog post.

Closing thought {#closing-thought}

So, lets start working towards a sustainable open source culture where developers can get (well) paid for their work.

After the post {#after-the-post}

After posting this earlier today the news dropped on hackernews that the author of mold, Rui Ueyama, is thinking about changing the license for mold/macOS due to its lack of funding. His twitter post is unrolled below.

I was optimistic when I started the mold project that I'd be able to earn a comfortable income in some way if it becomes popular. But I may have to admit that that's a bit too optimistic. I'm still losing my money after two years.

I have enough money that I earned when I was working as a full-time software engineer, but if I keep losing money, it's not sustainable long term. It's even a bit ironic that I had been asked by several big-name companies when mold/macOS would become available, since they wanted to use it for their multi-billion-dollar businesses. But no one gave me a financial support.

Part of a reason is because most companies don't have an internal process to start supporting an open-source project. If they need to buy a license, that's fine, that's part of a usual business. But giving money away to “free” software? There's no precedent and hard to justify. Given this situation, I'm seriously considering changing the mold/macOS license (not mold/Unix license) from AGPL to a commercial, source-available one. Something like individuals would be able to use it for free but companies have to pay.

I know some people are not happy about even thinking about it, and so am I. But to me it is more important to make the project viable long-term and grow into something that we can hire an engineer or two to accelerate the development. I haven't decided anything yet though!

Where to begin... {#where-to-begin-dot-dot-dot}

I just watched David Wilson's talk called M-x forever – why Emacs will outlast text editor trends. He gave this talk at EmacsConf 2021 which is a conference dedicated to Emacs. The talk made me reflect on my use of Emacs over the last years and then I realized that this year will mark 22 years that Emacs and I have been together. This (probably too long) article reflects on those years and dives into my use of Emacs.

First Contact {#first-contact}

Back in 1998 I was planning a move to the US. I had just finished my first professional programming gig writing a RAS Dialer for Freeler internet, the first “free” internet provider in The Netherlands. Pretty much everyone in The Netherlands (who had a modem and tried Freeler) was using my software to connect to the service. I was programming in various languages at the time, from Delphi (for the dialer) to Perl (yes, it was popular then!). This is when I first started playing with Linux and editors like Vi and Emacs.

When I moved to the US (San Francisco) I started working for Personify, a company focused on building an analytical platform for e-commerce sites. I started working in a small team which dealt with webserver logfile parsing. That sounds like a great job for Perl, right? My mentor worked in the same team and he guided me through the hectic time of working at a pre-2000 startup in Silicon Valley.

Picking Emacs for life {#picking-emacs-for-life}

As I was working closely with my mentor I started picking up on things he did. He was (and probably still is) a wizard behind the keyboard. He used Emacs as his editor. Naturally I gave it a try, but found it hard to really get productive with it and so I kept switching back and forth between Vi, Emacs and several other editors. It always amazed me how quick he was in getting stuff done. One day, my mentor told me to stop and take the time to learn my tools.

His reasoning was that when you learn your tool well it will not impede you from completing your task. You will be able to complete it as fast as you can simply because the tool becomes an extension of your thought process and it is possible to leverage the features it has to the benefit of the task at hand. It did not matter which tool I would choose, but pick one and learn it well. I accepted the challenge of working with a single tool for 30 days and see if my work speed would improve.

I chose to use Emacs, as it allowed me to look at the things he did. The availability of information on how to best use software was not as abundant as it is now. Now you can look up anything on YouTube or any blog, back then there was the Emacs Manual and other users that I ran into during technical meetups.

Now we are 22 years later and I still use Emacs everyday for pretty much anything. It has been with me through transitioning from Windows, to macOS and since 2017 full time on Linux. It came with me when moving between continents (back to Europe) and through various jobs at different companies.

Cheating on Emacs {#cheating-on-emacs}

I too have been tempted by new fashioned shiny tools that promised to be the next big thing in Editing. I even switched to Vim for a little while. The thing is, I always came back to Emacs. I think this is mostly due to the fact that new tools have something spectacular and then you want to adjust it and you find you can not do it to the degree that Emacs allows you to change the way it works for you.

While working with programming languages like Java the lure of IDEs has been quite tempting as well. In teams where pretty much everyone uses IntelliJ IDEA you stand out when just opening up Emacs. It often results in quite some interesting discussions as to what “makes a good developer”. Some people are quite unreasonable and think an IDE makes the developer, but I greatly disagree on that topic.

Serendipity {#serendipity}

Over the years there have been several serendipitous moments in the Emacs community for me. I will pick out 2:

• I started sponsoring Jonas Bernoulli in 2021 for his work on Magit and back in 2012 he sent in a patch for my worklog package which I only found out while preparing this article and looking at the logs of my various projects.
• I was referenced in a talk by Martin Clausen. He gave a presentation on a Clojure project and in the conclusion he talked about knowing your tools. We had been doing some live streams together working on Clojure projects and while he talked about using your tools effectively he casually dropped a “then you need to talk to this guy” and pointed my out in the crowd.

Giving back {#giving-back}

A YouTube series {#a-youtube-series}

In 2015/2016 I started working a little less and found time to do a Friday morning live-coding series. It featured me learning to write Clojure by building various projects. In the videos I, of course, used Emacs in pretty much every way possible.

I also created a series of videos called Productive Emacs in which I highlighted useful packages (focused on Clojure development). They were a big hit (at least I think so) and connected me to wonderful people like Mike Zamansky.

Writing packages {#writing-packages}

In my time with Emacs I have written and maintained some code as well. Most notably in 2003 I took over a package for tracking time (worklog) as I had a job where I need to track my time and naturally I chose to do this in Emacs.

I also have a grey theme out on melpa that is being used by several people. I always enjoy getting responses from the community when they like the work that has gone into making things.

Whenever I can I will post about some snippet of emacs-lisp I have written, such as my Advent of Code helper function. It retrieves the input for a puzzle during December and puts it into a file. It then prints the puzzle description and allows you to quickly get going. It is awesome to use your editor to make your life easier!

Providing patches {#providing-patches}

One of the most meaningful things in this entire ecosystem is to give back to the projects when you can. Whenever I run into a bug or oddity I will try and fix it. When my skill-set allows it I will send in a patch or documentation update to show my appreciation for the work people do. This entire community runs on people spending their free time working on code that helps many of us.

My configuration {#my-configuration}

Recently there was a twitter exchange with Bozhidat Batsov in which Stephen A. Ramsey calls Emacs a lifestyle choice as someone makes the remark that the people they know have been configuring Emacs as long as they have been using it.

{{< figure src=“/ox-hugo/twitter.png” >}}

I too am one of those that is always tinkering with my configuration. I think it is part of having such an extensible editor and using it constantly for everything. The community keeps making amazing packages that provide entire new dimensions to the use of Emacs (hi use-package, Projectile, Counsel, Ivy, Org-Roam, Company, and many many more) that it only makes sense to be critical and try out anything that seems useful and an improvement. The ease with which it is possible to add new functions to Emacs is amazing.

I said ease, but for new users it can be quite daunting to start with a configuration. That is why projects like Doom Emacs and Spacemacs are so important. I have tried both and I think the work done in them is amazing! I often go into their repositories and check out the packages they use and take snippets from their configuration.

A few years back I converted my pre-2000 init.el to a literal configuration using org-mode and babel. This allows you to treat your configuration as documentation and annotate it using the wonderful org-mode. Sadly I sometimes lack the discipline to properly annotate my configuration like Protesilaos does.

You can still check out my configuration in its repository. The wonderful thing of having a configuration in the open is that many people take from it. It has resulted in various connections around the globe that to this day exchange ideas and experiments using my configuration as a base.

Favorite packages {#favorite-packages}

So after all these years, there must be some favorite packages. Yes there are. It is important to note that I use Emacs for pretty much everything in my day-to-day live; from making presentations and documents in LaTeX, keeping notes and scheduling in org-mode, writing code in languages such as Java, C, Rust and Clojure and reading my Email. The list below is in no means a complete reference, but it gives a sense of what I do in my day-to-day life using Emacs.

Org-mode and Org-Roam {#org-mode-and-org-roam}

I think org mode can be seen as one of the most influential packages in the Emacs ecosystem. For me it has taken over most of my note-taking, document processing needs.

Lets start with my daily tasks. As a teacher I have many daily things to keep track of, from work that needs reviewing, classes that need preparing and the grading of papers. To keep track of everything and not loose sight of anything I have implemented a Getting Things Done (GTD) workflow.

Anything that lives in a browser is connected to my GTD system using org-protocol, anything that lives in Emacs is captured using capture templates. This means that anything that will take me more then 2 minutes to take care of will go into my GTD system and will be filed away with scheduling dates, deadlines and notes on the task itself. In my archive I have cleared over 10000 tasks in the current version of the system.

The article you are reading now is also an Org document. It lives in an archive called website and has an Emacs build script that generates this website in a Github Action.

As an extension to org-mode I use org-roam to keep track of knowledge snippets. This can be anything from development tricks, hacking methodology, background information on some technology to grading notes on papers. All this knowledge is captured in my org-mode archive and is accessible through a series of links in topic covering notes.

{{< figure src=“/ox-hugo/org-mode.png” >}}

Mu4e {#mu4e}

The use of org-mode continues into my Email. All my mail is read through mu4e. It seamlessly ties into my GTD workflow, its editing builds on the document processing I already do with org-mode and using various modules I can even read horrible HTML emails.

Most importantly, captures I have made from email into the GTD system will link directly to the email itself, so it is as if the system is one concise whole, making it very productive.

Magit {#magit}

As I put everything I find of value into git repositories I tend to use Magit quite a lot during the day. It has totally redefined how Emacs should do interfaces for tools and has shown the world how a good git interface can integrate into the editor. It puts anything else to shame in my opinion.

{{< figure src=“/ox-hugo/magit.png” >}}

Which-Key {#which-key}

A few years back I added which-key to my configuration after reading an article on discoverability of features. It is an amazing extension that allows you to press a key combination and it will pop-up a list of all following combinations that can be accessed from there. This greatly helps when you are trying to remember that one key sequence for that feature you don't use that often.

{{< figure src=“/ox-hugo/which-key.png” >}}

LSP / eglot {#lsp-eglot}

With the introduction of VSCode to the world Microsoft actually made something useful as well, the Language Server Protocol (LSP). The LSP is the thing that makes VSCode such a hit, it separated the editor frontend from the language understanding backend.

Emacs now has 2 LSP infrastructures, lsp-mode and eglot. I have tried both and eventually settled on using eglot for my daily programming tasks.

The lsp-mode package is the most extensive and feature loaded of the two, it also means it has a lot of configuration to tweak it to your liking. The package also takes care of installing the needed language server for your language and sets it up automatically.

On the other hand, eglot, is bare bones and configuration-less. Just drop it in and it works after manually installing a language server. It is simple and unobtrusive, and as I do a lot of screen sharing while coding I chose it over lsp-mode.

Both packages give Emacs an IDE set of features, such as context sensitive completion, formatting of code, refactoring, organization of imports and the execution of code actions on errors and warnings. It has redefined Emacs for me when it comes to writing code.

{{< figure src=“/ox-hugo/lsp.png” >}}

Projectile {#projectile}

The last of my favorite packages is projectile. As the name implies it is a tool to work with projects. As I said, I maintain a lot git repositories for anything I deem of importance. Projectile interacts with these git projects and allows you to quickly open files in the project, search them, run commands on them, switch between test and implementation code and so on.

As a productivity tool projectile makes code editing that extra bit enjoyable.

Helpful resources {#helpful-resources}

As the community is large there are several resources I keep track of to find new features, applications and packages.

Mastering Emacs : a book and website with cool and useful tricks in Emacs.

Emacs News by Sacha Chua : a weekly digest that summarizes the week of Emacs news, a great resource to read with a cup of coffee.

Emacs Reddit : the Emacs sub-reddit is extremely wonderful when it comes to sharing information. The community is great and supportive (who would say this about Reddit, right?)

YouTube : the following channels offer a lot of information; Protesilaos and System Crafters.

Closing thoughts {#closing-thoughts}

Emacs and I have been together for 22 years now and I don't see it changing anytime soon. Emacs itself is getting better and better with initiatives such as native-compilation and the Pure GTK patches. Its package ecosystem is in excellent condition and packages such as org-mode and eglot / lsp-mode make even the most demanding programming languages a joy to work with in Emacs.

Here's to another 22 years Emacs!

#writing #emacs

{{< figure src=“/ox-hugo/header.jpg” >}}

For the last 18 months I have organized the dutch Hack The Box meetups. Due to COVID-19 they have all been as a digital meetup, but not less entertaining though.

During my time organizing the meetups the Hack The Box organization supports me in various ways; they give me stuff to hand out such as swag or VIP memberships, they help organize speakers for events when we don't have one ourselves and they provide me with Hack The Box goodies every once in a while.

One of the “goodies” is to be named Hack The Box Ambassador. This is mostly just a title, but a very cool one :D.

As I just celebrated my first year as Ambassador I was interviewed for the Hack The Box Blog. A very nice article exploring my motivations to start hosting a meetup, how it ties in to my work as Lecturer at NOVI Hogeschool and the rewards I get from hosting the meetup.

On the blog I am no stranger however. In the last 6 articles I appear in 3 of them. The others explore the use of Hack The Box for academia, to study the field of hacking, and a case study on how NOVI Hogeschool utilizes the Hack The Box platform.

{{< figure src=“/ox-hugo/on-the-blog.png” >}}

Very cool to be recognized in such a positive way by a great community. Thanks!