IVan

Safer pointers in rust

Wed, 15 Oct 2025 18:53:17 +0200

For illustration purposes, suppose you want to have a struct First that holds a pointer to a string slice. It should have a method that returns the first character in said string slice. Storing raw pointers instead of using owning containers may give you a performance boost in some scenarios (always measure first!), and you may also want to do it to avoid that pesky borrow checker.

struct First {
    data: *const u8,
}

We will be storing the data as a pointer to unsigned bytes, since that is how strings in Rust (and most other languages) are represented under the hood.

In order to construct one, we will add a new method:

impl First {
    fn new(data: &str) -> Self {
        Self {
            data: data.as_ptr(),
        }
    }

To get the first character, we will add a first method:

    fn first(&self) -> char {
        let first = unsafe { *self.data };
        char::from(first)
    }

In a pointer to an array, the memory address stored in such pointer points to the first element of the array. So in order to just get the first character, it is enough to dereference it. Since dereferencing a pointer is obviously unsafe, we need to wrap this up in an unsafe block.

This will give us the first u8 in the array, but we want to return a char. A char is a 32bit code-point. If our string started with a multi-byte non-ASCII character, then our code would be incorrect, but since this is just an experiment, we will assume that we are only dealing with ASCII and just return it as-is.

We can then test our code:

fn main() {
    let name = String::from("Josh");
    let first = First::new(&name);
    println!("{}", first.first());
}

Which will print out: J.

As a test, let’s feed it a multi-byte code-point:

fn main() {
    let name = String::from("你好");
    let first = First::new(&name);
    println!("{}", first.first());
}

This outputs: ä on my machine, which is obviously wrong, but expected, since we are not handling UTF-8 at all.

This exercise is not about correct UTF-8 handling though, it’s about trying to make our unsafe code safer in Rust, by leveraging the tools that the language provides.

Consider what happens when we drop the String in variable name before calling println!:

fn main() {
    let name = String::from("你好");
    let first = First::new(&name);
    drop(name);
    println!("{}", first.first());
}

This compiles just fine. We can always choose to use raw pointers in Rust and skedaddle around the borrow checker if we so choose. There are many other unsafe escape hatchets if we find the borrow checker too troublesome and we really know what we are doing, which I might cover in another blog post.

This code of course has a use after free bug. When we call first(), we end up dereferencing a pointer to memory that has been freed, since it was owned by the String bound to the name variable. On my system, this code outputs nothing, but it may behave differently on your system, depending on a myriad of different things like the system allocator, the version of rustc, etc. It is undefined behavior.

We can use ASAN using nightly to check that we do in fact have a user after free, by running our example with RUSTFLAGS=-Zsanitizer=address cargo +nightly run :

==30967==ERROR: AddressSanitizer: heap-use-after-free on address 0x6020000000f0 at pc 0x00010232e678 bp 0x00016dad21e0 sp 0x00016dad21d8
READ of size 1 at 0x6020000000f0 thread T0
    #0 0x00010232e674 in first::First::first::h8e131cbea1cf814a main.rs:30
    #1 0x00010232e3ac in first::main::h7e742f6d761002ff main.rs:39
...

Lifetimes?

We could use lifetimes to make sure the compiler checks that we are not dereferencing the pointer if the owner goes out of scope. We can therefore make our struct First generic over some lifetime, which should be the same as the validity of our data pointer.

Big Rust does not want you to know this, but you can actually name your lifetimes however you want. They don’t need to be cryptic one-letter names like 'a.

struct First<'data> {
    data: *const u8,
}

Here I decided to make our struct First generic over a lifetime called 'data, since our First will be valid as long as our data pointer is valid. However, we can’t add it to our struct since we aren’t actually using this lifetime anywhere. We can’t just add a lifetime to a pointer, that was the whole point! We did not want to store a reference and worry about lifetimes! We chose a pointer because pointers allow us to by-pass lifetimes all together, but now we would like to tie our pointer back to one. Somehow.

We can always get a reference out of a pointer by calling as_ref on the pointer. And if we do end up storing a reference instead of a pointer, we will be storing a lifetime too, which is what we want. So I guess, if you want safe pointers, just use references. That’s literally why they exist.

But since this is just a convoluted example anyways, and we want to know how to make pointers themselves safer, let’s see how we can do this instead.

The rust compiler being as helpful as ever, already spoils the solution for this in its error message:

 1  error[E0392]: lifetime parameter `'data` is never used
  --> src/main.rs:1:14
   |
 1 | struct First<'data> {
   |              ^^^^^ unused lifetime parameter
   |
   = help: consider removing `'data`, referring to it in a field, or using a marke
 r such as `std::marker::PhantomData`

The easiest way is to just use PhantomData, which is a marker: we can use it on an extra field to give more information to the compiler. However, a marker compiles down to nothing, it is just there to help the compiler. In this case, we want to mark our struct as having a lifetime over our data pointer, but we don’t want to store a reference (because reasons), so we need a way to “store the lifetime itself” so the compiler keeps track of it for us, but not actually store anything.

struct First<'data> {
    data: *const u8,
    _marker: std::marker::PhantomData<&'data str>,
}

Adding a proper name to the lifetime makes things clearer. We act as if we were actually storing a reference to a &'data str, but we aren’t actually storing an extra reference. Just our plain unsafe pointer (I will like to remind the reader that a reference is also just a plain pointer under the hood and incurs no extra runtime cost).

We update our new method accordingly:

impl<'data> First<'data> {
    fn new(data: &'data str) -> Self {
        Self {
            data: data.as_ptr(),
            _marker: std::marker::PhantomData,
        }
    }
}

And now the borrow checker has got our back and forbids us from compiling the code:

 1  error[E0505]: cannot move out of `name` because it is borrowed
   --> src/main.rs:23:10
    |
 21 |     let name = String::from("Josh");
    |         ---- binding `name` declared here
 22 |     let first = First::new(&name);
    |                            ----- borrow of `name` occurs here
 23 |     drop(name);
    |          ^^^^ move out of `name` occurs here
 24 |     println!("{}", first.first());
    |                    ----- borrow later used here
    |
 help: consider cloning the value if the performance cost is acceptable
    |
 22 |     let first = First::new(&name.clone());

If we do

println!("{}", std::mem::size_of::<First>());

with our old implementation of struct First without the PhantomData, and then with our new PhantomData, we will see that the output is the same: 8 bytes (64 bits for the size of our pointer on my 64 bit machine).

This was just references with extra steps.

Please use references.

Making rustc output better assembly

Mon, 24 Mar 2025 15:07:53 +0100

I was profiling some of our workloads at work, and while reading some of the assembly output noticed that the is_zero method of the rust_decimal crate was being called quite a bit of times: not much, but enough for me to take a look at it. Our codebase is already pretty well optimized, and we have gotten rid of the low-hanging fruit in terms of performance, so any small improvement can add up quickly (and also small performance regressions, which will lead to a death by a thousand unoptimized cuts).

What really caught my eye though, was the assembly output. I was expecting it to be much shorter, but it somehow wasn’t, and had a bunch of jumps. I already knew the internal representation of their Decimal struct because I had to write some custom code to serialize it efficiently, so I knew the compiler could do better at generating its is_zero function. So I opened the wonderful Compiler Explorer website and started to dig in.

`Decimal` under the hood

In the rust_decimal crate, Decimal is represented as follows:

 struct Decimal {
      flags: u32,
     // The lo, mid, hi, and flags fields contain the representation of the
     // Decimal value as a 96-bit integer.
     hi: u32,
     lo: u32,
     mid: u32,
}

Of course, this is an internal detail and is subject to change, but when you deal with performance, you need to intimately know your data. The is_zero function states that a Decimal is zero if all the hi, lo and mid fields are zero.

 impl Decimal {
     pub const fn is_zero(&self) -> bool {
         self.lo == 0 && self.mid == 0 && self.hi == 0
     }
 }

This is the code that rustc gives us with -C opt-level=3:

 is_zero:
         mov     eax, dword ptr [rdi + 12]
         or      eax, dword ptr [rdi + 8]
         jne     .LBB0_1
         cmp     dword ptr [rdi + 4], 0
         sete    al
         ret
 .LBB0_1:
         xor     eax, eax
         ret

jne? cmp? So much code. So much branching. Of course, we are short-circuiting, which is branching, but I would expect the compiler to be smarter than that.

The bitwise approach

EDIT: This approach has been merged in the v1 branch

We can just compare all these fields at once. This should result in much fewer instructions, and fewer jumps (that could or could not be expensive, you should always measure).

Our new approach could look like:

 pub const fn is_zero(&self) -> bool {
     self.lo | self.mid | self.hi == 0
 }

This is the output that rustc gives us:

 is_zero:
         mov     eax, dword ptr [rdi + 12]
         or      eax, dword ptr [rdi + 8]
         or      eax, dword ptr [rdi + 4]
         sete    al
         ret

Much better. We or the bits together of these fields and store it in eax. At the end of the day, even though each field is a number, it is still made out of bits. We want to check all of them at once and avoid the extra branching and code that results in having to exit sooner if one of the numbers is not zero. By treating the numbers as just bits, we can achieve this in a more efficient manner. At the end of the day, zero is zero, so we can just check for it at the bit level. No fancy bitmasks going on here. Since it’s a logical or, if at least one bit is set to 1, the final number in eax will have a 1 in it. And you don’t need to be a computer science wiz to know that if there is at least a 1 somewhere in a binary representation of a number, then it can’t be a zero.

The unsafe way

⚠️ WARNING: This is not for the faint of heart, specially if you are a good boy rustacean and avoid unsafe. What I am about to show you requires a strong stomach. Reader’s discretion is advised.

This duplicate or is bothering me. I want to truly check it all in one fell swoop. Can I use SIMD somehow? Do I really need to?

If we look at the data more closely, we can see that a Decimal is made of 4 fields, 32 bits each. And wouldn’t you know it, rust has an unsigned 128-bit integer type.

We can just transmute the memory (a safer and fancier form of memory casting) to interpret the struct as one big 128 bit number.

 let num = unsafe { core::mem::transmute::<Decimal, u128>(dec) };

Since they are the same size, transmute lets us do it (another great safety feature from rust, you can still use unsafe, but you get a safer unsafe experience).

We can’t just check if this number is 0 and call it a day, since we don’t use the flags member, which is the very first field of the struct and is therefore also part of our number. To get rid of it, we can just shift those 32 bits out (the other way around, since we are running on a little endian machine, making our code technically not portable), with the rest being filled with 0 as they come in. Now, the whole content of our 128-bit number is composed of the values of the mid, lo and hi fields, and the rest would be zeroes, so we can now check for equality. The final code would look like this (transmute takes an owned value as a parameter, so we need to change the function signature. This is ok since Decimal implements Copy and it is only 128 bits):

 pub const fn is_zero(dec: Decimal) -> bool {
     let num = unsafe { core::mem::transmute::<Decimal, u128>(dec) };
     num >> 32 == 0
 }

This gets rid of the extra or:

is_zero:
        mov     eax, dword ptr [rdi + 4]
        or      rax, qword ptr [rdi + 8]
        sete    al
        ret

However, I would still expect to see a shift instruction, not an or. The 64 bit calling convention says that you can pack a small struct (which Decimal qualifies as) into registers, so I would expect to see a shift on a register and not even load from memory.

C++ and clang

Since this all seemed like something an optimizing compiler should be able to do on its own, I tried porting the code to C++ and see what clang did with it, since they are both based on LLVM (rust has its own fork though).

With the original implementation (the one with the short-circuiting &&) in rust, if we changed the code to take in a copy of Decimal instead of a reference, the assembly output is the same. If we port the same piece of code to C++ using the latest stable clang to compile, we get the same assembly output than in rust when using references, but when using a copy, clang is able to generate even better assembly code than our custom unsafe rust version:

 #include <cstdint>
 
 struct Decimal {
     uint32_t flags;
     uint32_t hi;
     uint32_t lo;
     uint32_t mid;
 };
 
 bool is_zero(Decimal dec) { 
     return dec.hi == 0 && dec.lo == 0 && dec.mid == 0;
 }

is_zero(Decimal):
        shr     rdi, 32
        or      rdi, rsi
        sete    al
        ret

Since the compiler only sees very little code to compile, it is unclear if rustc would end up putting our Decimal in a register too (seems likely), but what is clear is that clang was able to generate much better code from the get-go without needing to be too explicit about it as opposed to rust.

Results?

Our sample workloads got 2-3% faster with this little code change, which is worth it for our use case, since we try to squeeze as much performance as possible. Your mileage may vary, so always make sure to measure on your machine.

All in all, the unsafe version is not worth it for just getting rid of one extra or. It is less clear to read, more complex and error-prone. My goal was to make it output a shr instruction, but the compiler seems to be more stubborn (or maybe is more conservative and plays it safer when it has less context of when the function will be called, who knows).

Again, these were just tiny code snippets in a vacuum, you would need to measure for yourself, but what is clear is that using an explicit bit comparison yielded much better assembly than the original in our production setup.

Ubuntu, uutils and the elusive C replacement

Wed, 19 Mar 2025 15:07:53 +0100

Ubuntu just announced that they are considering using uutils as their coreutils instead of GNU. I am a big Rust fan (even though there are a bunch of things I dislike in it), and I would consider it my main programming language. Why use Rust here?

Why

Security is number one, and the reasons are obvious, so I won’t explain the benefits of a memory-safe language over a language such as C: that much is clear. But other implementations of coreutils have been around for longer and have been thoroughly battle-tested and audited (including GNU). Still, I do agree that using a memory-safe language is better, but memory-safety is not the only good reason.

The tooling around C is pretty archaic at this point and has pretty bad UX compared to Rust tooling. Rust in general is friendlier than C in all aspects, and this makes the codebase more approachable to new maintainers and people looking to poke into the source code. GNU source code is also notoriously complex, and complexity is also bad in terms of security (the more complex a system is, the harder it is to make secure). Part of this is because GNU supports everything under the sun (and adds extra non-POSIX functionality), while Rust doesn’t (limited by LLVM), but as a modern replacement, especially if catered to Ubuntu specifically, it makes total sense and is a great choice.

Except…

Except none of this is true. Well, some parts are, but not all. Let’s look at a very simple example in coreutils, the yes utility. This little guy’s only job is to print y or the first argument that it receives to stdout in an infinite loop. Super simple.

If we look at the GNU implementation we’ll see that it takes roughly 100 LOC. Huh? For such a simple loop? Not only that, but it also includes some extra headers, three to be exact, that now make it harder to follow:

 #include "system.h"
 #include "full-write.h"
 #include "long-options.h"

Also, why on earth is an IFDEF needed in such a simple program, and what is a CHERI?:

 #if defined __CHERI__
   /* Cheri capability bounds do not allow for this.  */
   reuse_operand_strings = false;
 #endif

Maybe it’s this. Still. Why have custom code for it? IT’S A SIMPLE FOR LOOP. Why architecture a simple for loop in such a way that it needs an IFDEF because of one obscure target. Madness.

The rest of the code is needlessly complex. All of this because of “optimizations” and “performance”.

For the yes utility.

At my day-job I work on performance critical applications and spend quite a bit of time looking at assembly. I like performance work. But this is completely unnecessary. It is harder to understand, more complex and therefore harder to work with. It will be easier for bugs (including security bugs) to creep in and will throw off most people trying to read the code and contribute to it. Plus, the coding style. Yuck.

Surely, everything is better over here in Rustland. The build system is better, right? No more horrible Makefiles, just cargo build. Let’s look at the source code

Well, I’ll be damned. Not only do we have one of those super-not-trendy Makefiles, we have two! And a GNU one at that! Plus cargo, obviously. And a flake, of course. But well, let’s find yes.

After looking for it for a while, I find its source code. It is split in 3 files. Three. Files. For an infinite loop. This does not bode well at all. One of them is called main.rs. Our entrypoint, great. Let’s look at it.

Oh no.

 uucore::bin!(uu_yes);

This is the whole code in this file. And it’s a fucking macro. Sigh. The other two files combined are even longer than the GNU version and are even harder to follow. A sad day indeed. Part of why it is hard to follow is because it uses a bunch of crates (Rust libraries) for handling all sorts of things, so the user must be already familiar with the ecosystem to follow the code.

So: more complex, more dependencies, more code…

Wait, dependencies? What? For a for loop?

Oh yeah. And not just one. Behold:

 [workspace.dependencies]
 ansi-width = "0.1.0"
 bigdecimal = "0.4"
 binary-heap-plus = "0.5.0"
 bstr = "1.9.1"
 bytecount = "0.6.8"
 byteorder = "1.5.0"
 chrono = { version = "0.4.38", default-features = false, features = [
   "std",
   "alloc",
   "clock",
 ] }
 chrono-tz = "0.10.0"
 clap = { version = "4.5", features = ["wrap_help", "cargo"] }
 clap_complete = "4.4"
 clap_mangen = "0.2"
 compare = "0.1.0"
 coz = { version = "0.1.3" }
 crossterm = "0.28.1"
 ctrlc = { version = "3.4.4", features = ["termination"] }
 dns-lookup = { version = "2.0.4" }
 exacl = "0.12.0"
 file_diff = "1.0.0"
 filetime = "0.2.23"
 fnv = "1.0.7"
 fs_extra = "1.3.0"
 # Remove the "=" once we moved to Rust edition 2024
 fts-sys = "=0.2.14"
 fundu = "2.0.0"
 gcd = "2.3"
 glob = "0.3.1"
 half = "2.4.1"
 hostname = "0.4"
 iana-time-zone = "0.1.57"
 indicatif = "0.17.8"
 itertools = "0.14.0"
 libc = "0.2.153"
 linux-raw-sys = "0.9"
 lscolors = { version = "0.20.0", default-features = false, features = [
   "gnu_legacy",
 ] }
 memchr = "2.7.2"
 memmap2 = "0.9.4"
 nix = { version = "0.29", default-features = false }
 nom = "8.0.0"
 notify = { version = "=8.0.0", features = ["macos_kqueue"] }
 num-bigint = "0.4.4"
 num-prime = "0.4.4"
 num-traits = "0.2.19"
 number_prefix = "0.4"
 onig = { version = "~6.4", default-features = false }
 parse_datetime = "0.8.0"
 phf = "0.11.2"
 phf_codegen = "0.11.2"
 platform-info = "2.0.3"
 quick-error = "2.0.1"
 rand = { version = "0.9.0", features = ["small_rng"] }
 rand_core = "0.9.0"
 rayon = "1.10"
 regex = "1.10.4"
 rstest = "0.25.0"
 rust-ini = "0.21.0"
 same-file = "1.0.6"
 self_cell = "1.0.4"
 # Remove the "=" once we moved to Rust edition 2024
 selinux = "= 0.5.0"
 selinux-sys = "= 0.6.13"
 signal-hook = "0.3.17"
 smallvec = { version = "1.13.2", features = ["union"] }
 tempfile = "3.15.0"
 terminal_size = "0.4.0"
 textwrap = { version = "0.16.1", features = ["terminal_size"] }
 thiserror = "2.0.3"
 time = { version = "0.3.36" }
 unicode-segmentation = "1.11.0"
 unicode-width = "0.2.0"
 utf-8 = "0.7.6"
 utmp-classic = "0.1.6"
 uutils_term_grid = "0.6"
 walkdir = "2.5"
 winapi-util = "0.1.8"
 windows-sys = { version = "0.59.0", default-features = false }
 xattr = "1.3.1"
 zip = { version = "2.2.2", default-features = false, features = ["deflate"] }
 
 hex = "0.4.3"
 md-5 = "0.10.6"
 sha1 = "0.10.6"
 sha2 = "0.10.8"
 sha3 = "0.10.8"
 blake2b_simd = "1.0.2"
 blake3 = "1.5.1"
 sm3 = "0.4.2"
 crc32fast = "1.4.2"
 digest = "0.10.7"
 
 uucore = { version = "0.0.30", package = "uucore", path = "src/uucore" }
 uucore_procs = { version = "0.0.30", package = "uucore_procs",
 path = "src/uucore_procs" }
 uu_ls = { version = "0.0.30", path = "src/uu/ls" }
 uu_base32 = { version = "0.0.30", path = "src/uu/base32" }

These are the dependencies used throughout the project (the yes utility only uses two), excluding the optional dependencies needed to run tests and build examples. Yikes.

If the whole point of using Rust is the safety, how is using this many dependencies more secure? Specially when using these in such a careful part of a system, the coreutils of all things. This is a huge supply-chain attack waiting to happen. The language design encourages using many libraries because of how easy it is to add dependencies and manage them. Again, the friendliness of Rust and the convenience it offers for developers becomes a double-edged sword.

Are we doomed?

So, to recap: we have a Rust version that is harder to read, harder to understand, has complex tooling around it, is not as efficient as the C version and is not as portable. You also need a more powerful machine to build Rust projects and run Rust related tooling like rust-analyzer, which brings my 16GB of RAM, 20-core cpu laptop to its knees when indexing huge Rust codebases, gating the access to such a fundamental part of any free operating system to people that have the means to afford expensive hardware.

But it does not have to be this way. Look at the OpenBSD version:

 #include <err.h>
 #include <stdio.h>
 #include <unistd.h>
 
 int
 main(int argc, char *argv[])
 {
 	if (pledge("stdio", NULL) == -1)
 		err(1, "pledge");
 
 	if (argc > 1)
 		for (;;)
 			puts(argv[1]);
 	else
 		for (;;)
 			puts("y");
 }

Delightful. It does exactly what you would expect it to do. It can’t get better than this. The extra line at the beginning uses pledge, an OpenBSD syscall that ensures that the program only ever uses stdio and nothing else (I am oversimplifying, but you get the idea). This makes it even more secure. How great is that! There are other nice C implementations out there (like busybox), but I really like how OpenBSD does things.

The C replacement

But C still sucks a bit. It still needs replacing.

So, is Rust a good C replacement? I don’t really think so. It’s a good C++ replacement, and I love Rust, I really do, but it can’t truly replace C. There are no other good competing implementations of Rust (it does not even have a specification yet, and even if you wanted to make one, it would be terribly hard because of how complex Rust is as a language). For something as critical as coreutils, we want something that is small, simple and portable. If not now, in the future, and Rust will never be as portable as C because of how big it is.

It can definitely replace C in some areas, but I don’t think this is a good example. To be fair, there is nothing stopping you from writing a Rust version as simple as the OpenBSD version, but it’s a matter of culture.

Rustaceans love to over-complicate code. They love their type system and building abstractions. They don’t mind using 200 libraries because they have amazing APIs that are hard to misuse, have incredible performance and are super high quality: so why wouldn’t you? But it tends to be overly complex and brittle. And breaking changes are common between create releases. Most libraries are not even in version 1.0 so they can break stuff without feeling guilty. Few crates like tokio or serde have had the guts to say “we are stable”. Even rand has not shipped a 1.0 version!

You can still write simple Rust code, but it is not as idiomatic. I appreciate the power that Rust gives you, I really do, and I will probably make some posts in the future singing its praises (and others criticizing it), but how the language is used in practice is also “part” of the language in a way. As an example, I don’t really dislike Java as a language, and think that the JVM is a phenomenal piece of software, but I dislike Java because of how the Java community writes Java: all the OOP attached to it, the “clean” AbstractFactoryVisitorSqueezer everywhere and how most of their programmers wear suits.

Other modern “C replacements” focus mostly on performance, like Zig and Odin, but are not simple at all (despite how the love to say how simple they are). Which is OK! They are definitely simpler than Rust or C++ (although that is a very low bar), but not as simple as one would like. They seem to be very popular in the Windows game dev crowd, and for good reason, as video games really benefit from a language that puts performance front and center, but are not very UNIX-y. Zig does not even list any of the BSDs in its download page.

Go is the only one that carries the torch, but too far. First of, it is not “simple”. It has a pretty complex runtime with a garbage collector. So, not really a good C replacement as far as I’m concerned.

Down the rabbit hole

The Hare programming language is my only hope so far. It is made by people that really love UNIX, that live and breathe it and fully understand its values and want to enhance the good parts (while making the bad parts better). It has a specification and very simple compiler (the backend is not LLVM, but QBE, how amazing is that?). While still in development, it shows great promise and I can’t wait for it to become more stable. The only thing so far that I don’t like are how it uses slices. I think Go slices are a very bad abstraction, and I hope Hare can mark a slice as immutable so that it is clear that it is only a view into data (and hopefully the compiler can make sure at compile time that you can’t append to it, for example). Other than that, I am extremely optimistic. Just take a look at the website and see the rest for yourself. You will quickly either love it or hate it. I’m in the love-it camp.

Just to highlight how much the Hare team gets it, they even have a repo of coreutils ported to Hare as a language showcase! And look at their yes implementation:

 use fmt;
 use getopt;
 use main;
 use os;
 
 export fn utilmain() (main::error | void) = {
 	const help: []getopt::help = [
 		"output a string repeatedly until killed",
 		"[STRING]",
 	];
 	const cmd = getopt::parse(os::args, help...);
 	defer getopt::finish(&cmd);
 
 	const s = if (len(cmd.args) == 1) {
 		yield cmd.args[0];
 	} else {
 		yield "y";
 	};
 
 	for (true) {
 		fmt::println(s)!;
 	};
  };

Perfection!

Micro$oft decides what code gets to run on your machine

Fri, 02 Feb 2024 19:29:53 +0100

A couple of days ago I installed the FLTK package for MSYS2 on Windows. That package contained the FLUID interface designer for FLTK as a binary, a binary that I tried to run.

I was not surprised when Windows Defender flagged it as malware and quarantined it for my “safety”, as it’s not a binary that many people download. I don’t like this approach to flagging software, as it results in many false-positives and hurts smaller/indie developers, marking their software as “unsafe” and turning off potential users that might not know better. This ends up pushing everyone that uses a Windows computer into a world of “trusted” Microsoft apps (where they can use whichever criteria lines their pockets better to vet these apps, taking away agency from their users and consolidating their monopoly over home and office computing even more). It also pushes users into using the most popular, shitty and mostly proprietary mainstream applications, since those won’t be recognized as potential malware.

Anyhow, I proceeded to open Windows Defender to put that binary into the exceptions list when, lo and behold, it prompted me to sign in using a Microsoft account!

But the worst was yet to come…

Microsoft was forcing me to subscribe to Microsoft 365! To configure their stupid antivirus that I can’t uninstall in the first place! There was no option for me to skip this. To add insult to injury, some time later I was compiling one of my own Go programs and it quarantined my own binary. Again! I can’t even run my own software!

In other news: water is wet, Stallman was right, the sky is blue and Microsoft is a cancer on computing.

First post

Wed, 24 Jan 2024 21:09:59 +0100

This is my very first post. I intend to keep the entries on this blog short and frequent. I don’t want to get too fixated on making sure that there aren’t any typos, or double-checking every single word I write. This will be my personal brain dump of sorts. Welcome.