marisa's "blog"

I recently switched to using Linux for my desktop workstation again, in the form of a System76 Oryx Pro. I'd previously used an iMac primarily with Windows bootcamped onto it (for game compatibility). It took me a while to realize, but at that point, I might as well have used a Windows laptop. The iMac, for how nice and quiet it is, is pretty useless as an iMac when you just run Windows on it, so I decided to sell it and get something else, maybe even something that's portable. After a while, I settled on the Oryx Pro.

Ordering and delivery

I live outside of the primary range of delivery for System76 since they're an American company, but thankfully they ship worldwide (though that comes with a ~100€ shipping fee). There was also a ~350€ import tax that I hadn't really anticipated since I never get things imported.

I went for a pretty baseline model with 16GB of RAM, an RTX 2060 and a 500GB NVMe SSD. You could go a lot more powerful, but even at this configuration, it'll cost you around 1700€. I chose “3-day quick assembly” (an extra 50 bucks) because I wanted it to arrive before Christmas. Their staff was very nice in communicating the progress of the assembly, but I would have preferred if they hadn't tried to call me (it's a nice gesture, sure, but because of Reasons it gives me the creeps when someone tries to do that). The shipping, too, was timely, and with the exception of the customs holdup taking one day too long because UPS' website didn't function, it came on time.


The laptop itself looks very nice. I especially like the back cover, which looks like some kind of weird futuristic thing, but not in the “Gaming Laptop” sense:

picture of the backside of the laptop

There's a bit of chassis flex everywhere, and the hinge isn't as tight as I would like it to be, but for a 16 inch laptop, the build quality is nice overall. The keyboard feels good too. There's a bit of travel, and it stays quiet (quieter than a ThinkPad keyboard), but it's still satisfying to type on. There is some weird key placement going on, specifically with the right shift key, which is cut in size in favor of the up arrow, which, coming from a ThinkPad keyboard, makes me hit the arrow by accident a lot of times. I also wish there was a configuration option to remove the numpad, since I never use it and never will, but it's something that's fairly easy to get used to. Oh, and it has backlighting in different colours, if you're into that.

The trackpad is silky smooth. It feels like you're gliding on ice, it's great. There's a good selection of ports, two USB 3, two USB-C, full-size HDMI, audio ports, full-size Ethernet, full-size SD slot, and a Kensington lock.


Preinstalled with the laptop comes Pop_OS!, which takes the cake as the most awful distro name to come preinstalled on something. That being said, I've been using it for a bit now and it's been pretty nice! It's based off Ubuntu, which, for all its flaws, gives you the broadest range of software availability, and is arguably one of the most newcomer-friendly Linux distros. Pop uses a customized version of the GNOME shell, which looks pretty good, and while I'm not a huge fan of the size of GNOME's window title bars, it does make for a nice experience overall.

The primary reason I've been running Windows and/or MacOS is to play Final Fantasy XIV, a MMO that unfortunately only really runs well on Windows (the official MacOS version is nothing more than a Wine wrapper). However, after a couple hours of fiddling around with Wine and Lutris, I managed to actually get the game to run, and with about 90% of the performance I'd have on Windows! This is mainly due to DXVK, a Wine tool that translates DirectX system calls to Vulkan system calls (I believe), which makes it possible to play many AAA video games on Linux. The only downside to this is that while playing the game, the fans on this laptop run at maximum speed, even though it doesn't really get hot, just warm, but I'm willing to chalk that up to Wine or something.

On everything else, though, the fans either run really quiet or with moderate speeds, but it never really gets annoyingly loud. I haven't really felt the laptop get hot until now, either.

It's worth noting that you can only use the RTX card in the laptop if you “boot” into the desired compatibility mode (this can either be the RTX, Intel integrated graphics, or some sort of hybrid mode). You need to reboot to switch between these, which I think takes a bit longer than a normal reboot, but aside from battery life, there's nothing that really stops me from using the RTX all the time (at least at my desk). Additionally, external monitors only work in RTX mode.

picture of my desktop under pop os


I'm pretty happy with this laptop. The build quality is good, the Pop_OS! distro is decent enough for my liking, it's very nice to have a desktop-grade GPU inside such a (relatively) compact laptop. System76 also sells other, smaller and less expensive laptops on their website, so if you're American, that might be worth checking out (they have some with coreboot too). I think if you're in Europe, there's some companies that do almost the same thing as System76 does in the US too, but I forget what they're called.

Today we released Rustlings 2.0. There's some interesting things in this release:

  • Exercises are now indexed by name, not by file name. This means that where previously you had to input a long path with rustlings run exercises/primitive_types/, you can now shorten it to rustlings run primitive_types1
  • rustlings watch will now require the user to delete a comment called // I AM NOT DONE to proceed, even when the exercise compiles or tests. Many of our exercises encourage the user to try out multiple different solutions, which was not possible to do before, since you had to move out of watch and manually verify the exercise using run. rustlings verify is also affected by this, but rustlings run is not.
  • There is a new way to interact with hints. Hints are not at the end of the file anymore, instead, you can view the hint(s) for a given exercise using rustlings hint exerciseName. Multiple people were having problems with hints being visible due to their screen heights or their autoformatters not playing nice, which is why it was refactored.
  • Rustlings now self-checks for the existence of rustc before running, in case you somehow installed Rustlings without having rustc.

A massive thanks to Roberto Vidal for pairing with me on some of these issues and helping push this out.

Significance of a breaking change

This release isn't all that special in terms of feature density. We haven't added or removed any exercises, but the reason we've decided to release a new major version is because we introduced what we believe are breaking changes.

Rust projects usually try to abide by a standard known as SemVer, which attempts to quantify the long headache of software versioning into something that makes sense in people's heads. The short version of it is:

  • Bug fixes –> Increment Patch (0.0.1 to 0.0.2)
  • Feature additions and enhancements that are backwards compatible –> Increment Minor (0.0.1 to 0.1.0)
  • Features, Deletions, Enhancements that are backwards incompatible –> Increment Major (0.0.1 to 1.0.0)

The latter of those three cases includes breaking changes, which means changes that make the new API of your software incompatible with how it was used before.

The problem with our changes is that, say, refactoring the hint system (aka introducing the rustlings hint command) technically doesn't produce a breaking change, as we're only adding a feature to our API (the Rustlings CLI). What we're getting at is the limits of a technical specification such as SemVer, which fails to address the human-centered side of software.

Admittedly, and in defense of SemVer, dealing with humans is really hard, and I'm not criticizing for that, but for software like Rustlings, which thousands of people use for learning Rust, we can't purely rely on a technical spec for releases.

Releasing software for humans

How then are we going to solve this dilemma? It seems like we'll have to throw some existing conventions out of the window and make our own. What we came up with is more or less specifically aimed at Rustlings, and it's partly based off SemVer, and partly based off what our intuition tells us:

  • Bug fixes –> Increment Patch
  • Feature additions, or backwards incompatible changes that only affect a small part of the exercises (changing one exercise or changing one category of them) –> Increment Minor
  • Backwards incompatible changes in the CLI source or changes that modify all exercises –> Increment Major

When I say “based off our intuition” here, what I mean is that we took into account how people using Rustlings will perceive these changes. The important thing to take into account is that the way most people use Rustlings is very limited – they download it, do a bunch of exercises, and then it likely sits on their hard drive untouched for a long time. This isn't a bad thing, and it does mean we can get away with introducing breaking changes on a smaller scale as long as it affects only a specific subsystem. Not many people are going to do an exercise, wait a year, update Rustlings, and then do the exact same exercise again.


So what's the actual takeaway from this? I guess it's that if you're designing software for teaching people, or just people that aren't software developers, consider thinking about their perspective when using your software before you blindly adhere to SemVer. Again, not saying SemVer is bad, but there have been some people that seem to believe adhering to SemVer is the best thing you can do in any situation, to which I disagree. I believe knowing who you're making software for is the best thing you can do in any situation.

I logged onto GitHub today, and got greeted with this lovely message:

As many might have heard, GitHub started enforcing the stricter regulations set by the US government with regards to international sanctions recently. What this actually means is unclear to even the people who are directly affected by it, as GitHub only offers this page as a meager explanation. From what I can tell, I've lost access to all of my private repositories, as well as the ability to create new ones. Also, the site seems to randomly slow down sometimes, and I get weird error messages sometimes, indicating a 500 HTTP response, but those are fixed when I try to perform the action again.

I don't really expect this to change anything with regards to the monopoly GitHub posesses in the version control and code collaboration space, as the majority of people affected seem to be from Iran, and not from its primary user base, the US. I believe I've only been affected because I accessed my repositories from Cuba once, which they must have found out by checking my IP history. Needless to say, since GitHub provides a possiblity to file an appeal, I'm filing one unless they start asking me for my personal information. Not that I'll be using GitHub much anyways, but it would be nice for employability reasons.

Update: They require you to submit your ID and photographic evidence

UPDATE (8/25/2019): This afternoon, I got completely suspended from my GitHub accounts. The reasons (and implications) of this are something I don't want to discuss here, but I've spent the last month(s) moving all of my stuff elsewhere and won't be using GitHub any longer.

Should I be moving from GitHub?

The only realistic alternative to being on GitHub, that is, moving from GitHub explicitly as a political response to their collaboration with the US regime, is hosting your own Git server. I'd recommend it to anyone, just as I'd recommend moving off Slack (who have pulled the same kind of shit) and Discord (who apparently collaborate directly with the Department of Homeland Security). Even if you're a big project, now is the time when you should be evaluating whether you want to prioritize being on GitHub over categorically excluding entire countries from collaboration. This situation isn't going to get better, it's going to get worse, and one of the most thoughtful things you could do as an Open Source developer is to keep that in mind.


There's a fair amount of Git hosting & collaboration alternatives these days, and I've tried some of them:

  • GitLab: This is what I currently use. It's a bit bloated, but if you have enough money to shell out for a VPS with 8 gigs of RAM, it works just fine and has enough features to replace at least one of your existing external tools.
  • Phabricator: It's clearly designed for larger teams, but if you're willing to get your hands dirty in some PHP hosting configuration, it's a good alternative and has about the same amount of features as GitLab, plus the design is (IMO) better (supports HG and CVS, too!).
  • BitBucket: Never used it, but it's hosted in the US, and it's Atlassisan. Make up your own mind.
  • Gitea/Gogs: Also haven't used it, but seems nice. Might lack a few features?

If there's any self-hosted alternatives that I'm missing, please recommend them to me on Twitter!

(It's best to read this blog post after reading Steve Klabnik's The culture war at the heart of open source and What comes after “open source”, in my opinion)

I think most of us once thought that Free Software was great. Then, as we gradually became more aware that most of the originators of the Free Software movement are huge pieces of shit, we steered more towards Open Source as a morally and logically just model of software distribution. Over time, I've become more and more disillusioned with both movements and over the past months I've finally decided that I'm not going to continue publishing open source or Free Software unless it's a collaborative project or unless absolutely required. Let me elaborate a bit on why.

What's wrong with Free Software?

Free Software, in its essence, is a utopian philosophy centered around the same notion of “freedom” that you would commonly hear from people that reply to any mainstream American politician on Twitter. It's this idealistic perception of reality that at first enthralls a lot of people. Who wouldn't want to live in a world where all software is free to give away and to use as long as you make it publicly available under the same terms? Where everyone enjoys the same benefits? Everyone, surely!

It's a nice pipe dream, but we live in a world with harsh inequalities, including in our sector of work. To start, not everyone is able to work on software in their off hours. This is something completely unheard of in most other fields of work. Especially in a market economy, the thought of someone putting hundreds of hours into a product and then offering it for free to the rest of the world is very atypical. At one point, some of these people came together and decided that distributing a product, irrelevant of how much labor went into it, for free should be the new standard. Consistent with their notion of “freedom”, they also decided that if you use and modify the product, you should have to put up your derivation under the same terms. There's clearly two different fronts covered here:

  1. The usage or distribution of the software. This is what copyleft licenses are all about, ensuring that the people who use the software follow a certain set of rules, most of the time centered around modification and attribution.
  2. The production of the software. This isn't as apparent as its distribution, so most people just take it as a given, which is why the Free Software movement makes no attempts at fixing that. The immense amount of labor that goes into producing a software artifact is usually ignored, and instead some abstract notion of “rights” that usually don't benefit the developer are enforced.

Developers who aren't in as privileged a situation as those people who only install Free Software on their computers will realize that if we wanted to make sure that our “rights” are protected and our interests represented, we would encompass the entire software development lifecycle, not only its distribution.

What's wrong with Open Source?

Did you think the ignorance of Free Software was bad? Cool, Open Source takes what little rights were given to the developer and throws them away. The most prevalent OSS license, MIT, gives all rights to the consumer. What if that consumer turns out to be manufacturing drones that kill children in Yemen? Doesn't matter, and even if it did, you don't have any rights to enforce it (and even if you did, their lawyers are better than any you can muster). Keep in mind that a copyleft license would at least require Lockheed and Raytheon to publish a little sidenote saying “ah by the way here's the source code for the library we used”, which is so much better, right?

Free Software was born from idealistic libertarianism, and Open Source was born from realistic liberalism because Free Software didn't give companies enough rights.

What are the alternatives?

Being conscious of whose interests you're serving is the first step. Most solutions to this will not work if there's no broad awareness of the underlying problem. Steve Klabnik has theorized a number of solutions, but I don't necessarily agree with them (aside from there probably never being enough popular consensus around them). What we have is an unjust social structure that effectively holds itself up by exploiting people's labor. As time has proven with other, similar social structures, the only useful way to get rid of them is not via reform.

Frankly, this issue requires a lot more thinking upon to come up with any even potentially viable solutions, so until then, here's what I'll do:

  • Not publish any more open source software unless it's required by an employer or similar
  • If I do somehow end up publishing open source software, license it under a License Zero license

I don't think a new license is the answer. Companies can easily bypass licenses by sheer force of intimidation, and the legal system certainly isn't set up to defend workers' entitlement to their labor. Rather, we need to rethink our approach to balancing production and distribution of software. I'm not sure how to do that, but I'm rather confident that this will ultimately happen if we build a movement around it.

What about paying maintainers? Paying maintainers won't work on any scale that's larger than, say, the 300 biggest open source projects. GitHub Sponsors is largely designed to work on a user-to-user basis, which makes it identical to crowdfunding (plus they're letting the people with the most social capital in first lol). Ultimately, it's trying to reform a system that was created to be unequal from the very beginning.

So are you saying if I maintain a large open source project, I should just make it private?

I also maintain a rather large open source project, and I'm not planning to take that private. Although if you feel prepared to face an incredible amount of backlash, but show how much the industry relies on institutionalized exploitation, go for it! I'd envy you.

I disagree!

If you have tangible points that go beyond disagreeing with “the software industry, Free Software and Open Source are built upon exploitation of developers”, feel free to put them forward. Or don't.

And remember: Complacency is complicity :)