wasp.dev

New Year, New Wasp

Thu, 23 Jan 2025 16:45:10 +0000

Well, 2025 is off to one hell of a start, isn’t it? We’ve already had two new spaceships launching into orbit, the richest man in the world totally not doing a fascist salute at the inauguration ceremony of the new president of the US, even the announcement of the Nintendo Switch 2 (finally)!

Of course it all pales in comparison to the fact that wasp.dev now hosts my microblog, my Instagram replacement and my Goodreads replacement, all fully federated with the Fediverse and fully selfhosted on a fantastic OVH box where we (well, mostly Roberto) have finally set up a good future proof install of NixOS.

So I thought that it might be a good idea to keep going with the creative flow and maybe pick the blog back up as well, though of course being able to configure a couple of Nix flakes is a completely different level of effort than writing even one post. But then I remembered the #100DaysToOffload thingy that was making the rounds in my corner of the internet a couple of years ago, and reading the page made me realize that there’s one really good piece of advice in there.

Just. Write.

You see, over the years I’ve drafted a million posts for this blog, ranging from the technical today-I-learned to the novella-length “this is my Emacs setup and this is why you should care”, but they’ve never ended up being “good enough” to be here, because for some reason I thought this had to be some kind of shrine to perfect writing where everything is perfectly edited, super relevant for everyone and of course interestingly written. Which is, of course, why my only published post is a tutorial for changing Exchange Online calendar permissions, clearly.

So I decided that maybe it was time to actually write about stuff. After all I’ve just installed a billion different ways to publish content on my server, so I might as well have something to actually publish on it, right? And maybe those infinite drafts could actually be good enough if I just finished and posted them, instead of leaving them in the private repo behind this site - hosted on this same server, of course, on our Forgejo instance.

And hey, maybe I do have something to add to the conversation. It might be interesting for someone to find out how - or why, god forbid I write something not technical for once - I had to patch the Nix flake of Bookwyrm to have it work on the latest release of NixOS, or someone might even be interested in reading my ideas about, I don’t know, the state of the world, or the fact that Cory Doctorow is basically an oracle and predicted most of what is happening in the world 15 years ago, you know, stuff like that.

After all it’s 2025, and it is about damn time that we start taking back the monopoly that Big Tech and social media have on dumb, useless content, right?

So yeah, here I am. Maybe I’ll write 100 posts in 100 days. Maybe I’ll write 100 posts iby the end of 2025. Or maybe I’ll drop off after 15 posts, because God knows what will happen.

And you know what? That’s completely fine, because this is my space on the internet. And it’s about time I do something with it.

This is day 1 of #100DaysToOffload

Change all Exchange Online calendar permissions with Powershell

Fri, 05 Jun 2020 12:00:00 +0000

We have a script at work that runs every night and sets the default permissions on all Office 365 calendars to LimitedDetails, or “View availability data with subject and location” as the Microsoft Documentation says.

Sounds simple, right?

Well, it is. Or, rather, it was. But then things started breaking.

First we found out some users didn’t have the “Calendar” default calendar, but only had the italian localized “Calendario” folder. Ok, easy enough, we can work around it with an easy “calendar” regex… except every user also has a Calendar Logging hidden folder, so we have to exclude that… still, simple enough: Where-Object { $_.Name -like "*calendar*" -and (-not ($_.Name -like "*calendar*logging")) } and we’re done.

Except no, not really. Because users can import other calendars and they will show up in Outlook in the calendar list… and in the Powershell cmdlets as well, obviously, and they will error out when trying to write permissions to them since they’re not an actual calendar but a link. So, time for another easy workaround: a little Get-MailboxFolderStatistics here, a little Where-Object { $_.FolderType -eq "Calendar" } there and we’re done.

For now, at least. Because, obviously, people can have spaces in their name, right? Well, if only Powershell didn’t break up parameters with spaces… and so we have to combine the user’s identity to the calendar’s identity and wrap it all in quotation marks to ignore the spaces… this one is really easy though: "$($Mailbox.Alias):\$($Calendar.Name)".

Too bad by now the script has grown unreadable, ugly and workaroundish… and we’re not writing Bash here, Powershell is supposed to be readable and easy to comprehend! Ok, time to rewrite the script, this time the right way!

So, here it is, in all it’s glory, a whopping four lines of Powershell that took a month to write and will probably be obsoleted soon since the new Exchange Online V2 Powershell module has just been released to GA:

foreach ($Mailbox in $(Get-Mailbox)) {
    $Calendar = Get-MailboxFolderStatistics -Identity $Mailbox.Identity -FolderScope Calendar | Where-Object { $_.FolderType -eq "Calendar" }
    $CalendarIdentity = "$($Mailbox.Alias):\$($Calendar.Name)"
    Set-MailboxFolderPermission -Identity "$CalendarIdentity" -User Default -AccessRights LimitedDetails
}

This snippet takes into account the possibility that a user has multiple calendars, the default one of which isn’t just called “Calendar” but can be localized into whatever language Office 365 likes. Oh, and the user can have spaces in its name, of course. Hopefully we’ve caught all corners this time…

Let's Build A CPU!

Mon, 16 Dec 2019 12:00:00 +0000

Welp, I’m building a CPU. At least, I hope. But, let’s rewind a bit.

A few months back, I realized most of the projects I had in mind and wanted to try at some point had something in common: I really wanted to build a CPU, somehow. I wanted to make a GBC emulator, and that’s obviously a CPU. I wanted to build some kind of simulation of automated behaviour, and that’s also a CPU. I wanted to make a disassembler and decompiler, and guess what? Making a CPU includes those, if you’re not starting from scratch.

So, I decided to make a CPU. That was months ago, and I didn’t really make any kind of progress until today, except some basic research. Why? I’m convinced the main reason was that I had no one to hold me to my decision, since I told no one like most of my projects. Here I am now, telling you, yes, you specifically, to hold me to this.

I want to make a CPU. From scratch - or at least reimplement “clean room style” an existing CPU, first in software then maybe on a FPGA board if I ever get there. The roadmap currently looks something like:

Find an easy to replicate and understand architecture - all signs are currently pointing to the 6502
Find as much reference material on it as possible
[We’re here]
Learn to code in ASM for the selected architecture, and get really comfortable with it
Write a disassembler for the selected architecture, and get it working really well
Write an emulator for the selected architecture, and get it working perfectly
Pick the simplest instruction for the architecture and think about how it was implemented
Implement the instruction in a logic simulator
Repeat the last two steps for a few more instructions
Build the rest of the instructions upon the easy ones implemented in the simulator
Optimize the design, if possible
Build the design into an FPGA, if possible - while learning about FPGAs since I know nothing about them :D

Of course, this is going to take a while - I’m hoping to get at least a complete emulator done in a few months, if I stick with this, and then decide where to go from there. There is a massive amount of work to do, and a lot of stuff to learn, considering what very little I know about ASM programming I learned back in high school and I know basically nothing about CPU design and low level architecture.

I’m probably going to use C# for the non ASM parts - the disassembler and emulator - since it’s the language I know best and this is not a language learning exercise, so I don’t want to waste time on useless stuff. The code I write is probably not going to be open source, since it doesn’t really contribute anything to anyone’s project except maybe causing some headaches for experienced ASM coders asking themselves why I did stuff the way I did… but I’m gonna post snippets here, and probably dump the complete projects (ASM programs, disassembler, emulator, …) on Sourcehut when they’re done. I just don’t want to maintain incomplete stuff out there on the internet, since that causes significant overhead. I might stream parts of the process on Twitch, if I ever get around to setting up my channel :^.

The first goal I’m setting for myself is to finalize the architecture decision - though that seems pretty final since the 6502 looks simple enough and the instruction set is very small and extremely well documented - and build a few of the “usual suspects” to familiarize myself with the ASM syntax: Fibonacci sequence, Collatz conjecture, Project Euler’s solutions and so on.

I’ll post back here for the big milestones and for interesting stuff I find out, and I’ll keep Twitter updated with anything noteworthy - if I remember Twitter exists for long enough this time, so subscribe to the RSS or follow me on Twitter for updates on the project!

Oh, and the “BCP” tag stands for Basic CPU Project. I couldn’t come up with anything better, and a quick search didn’t turn up any conflict. And BCP sounds nice as an architecture name, right?