Slowly beginning to not like microblogging anymore (but for a particular reason I'm still trying to hash out, despite the joys I get from it). Unrelated, I sent out a newsletter entry about my headspace (from a political stance) and wrote about literature and revolution on my blog (thank you Toni Morrison for inspiring it).

I was suggested before to do something like a focused letter on topics (specifically on labor, which I have been toying with a lot) but I do not like the idea of "constraining" scope because everything is inherently connected. That doesn't mean I haven't started on it but I am still nervous on putting it out there. I write for myself first to organize my thoughts in a way I can assert my understandings and secondly to share so I can have others I trust help course-correct and grow our collective understanding.

The Assumed Role of Literature in Revolution

The act of reading and writing, as with many actions one can take, is a form of resistance, an active political tool of reassessment. What you read, choose to profess and would deem worth “your time” all influence many parts of you - from how you engage people to what time you end up going to sleep. It’s not necessarily trapped to a particular genre, we see effectively bored white men rehash their opinions of hegemonic violence in their many collections of patriot fiction or third-person accounting of events of foreign invasions described as “righteous war”. We have activists retelling their times of imprisonment for demanding less than the bare minimum from an establishment dedicating to making life a reminder of the violence that’s been become "normal" to lands for hundreds of years. And on the same hand, some of the most infamous names in history hadn’t the ability to do either - they communicated clearly and had trusted folks that did the writing and reading they needed as they focused on their own works. In reading works from people of many backgrounds and walks of life, one can be reminded of their placement among them, as nothing happens in a vacuum; despite what media and plutocratic society tells us via their paid spokespeople and eager parrots.

I am afraid. I do not believe that the idea of this violence is made clear, nor is it of immediate concern, even to some of those holding strong sentiments for community well-being and development. Even the case of book banning within the United States, a now-trivialized situation by mainstream media of authors having their visibility in their intended place of reading, does not focus enough on how this is an extension of the general nature of the United States’ need to maintain a state of both disillusion and lack of self-guided intellect. Additionally, according to mainstream media, there’s no clear interest in longer and more insightful discussions between representatives, not even on a hyper-local level, when news stations were once more willing to report on these things - in part of commercial social networking’s ability to create spaces of aggressive thought collapse. Tying that with the nature of language as a tool of both oppression and maintenance, there’s little reason to expect people to stumble upon concepts that lead them to truth, there isn’t enough capital that can be made from that (whereas masculinity and its tendrils intertwined with capitalism tend to be, by design and shaping by the market’s directors). These things, the inability to acknowledge the role of book banning in maintaining a populace of disillusioned and disinterested people, the lack of open debate and discussion free of the corporate and professional class of “political commentators” (a substitute for the direct voice and direct words of the people) and now the inability for people to directly understand and parse what impact local laws that are both illegible to the public like Florida State Bill 256 in 2023 or more encompassing and equally illegible like Presidential Policy Directive 20 are tools of weapons against the people who reside within the United States. Despite what the media industry has repeated on behalf of the government, national security does not mean the security of life and stability for those outside of the realm of the political industry, but more on the ability of a nation to maintain its ability to continue its behavior with no restraint.

What does one do to combat this (can we truly)? The most immediate answer under capitalistic society is to produce even more material - but this is shortsighted as the material has to be engaged with, discussed and provide actionable output lest it becomes what James Baldwin had described (in references to books) as a meal for “the affluent populations". These people (which is us), "which should have been their [poor working class people] help, didn’t, as far as could be discovered, read, either - they merely bought books and devoured them, but not in order to learn: in order to learn new attitudes”. We are crafting new ways to cope with the new middle class's uncomfortable place in society, providing these people with new language to further entrench themselves as the “new” lords and aristocrats. Obtaining awards to address but never directly challenge, to critique but never truly attack, from the same institutions of violence does nothing but provide a yet another opinion into the void of toothless insurgent actions. These eagerness to run to these behaviors are as strong as the notion that voting makes a difference in a country where the people, places and roles that need elections are inaccessible, invisible and non-controllable by the American public. We have to push harder than dancing around topics and return to rooting ourselves in what “action” means. Wikipedia defines action from the lens of philosophy as “an event that an agent performs for a purpose, that is, guided by the person’s intention”. We work within a world of many performers whose intentions tend to centralize around extraction, coercion and demolition of the meanings of humanity. We collectively accept the concept of inaction, the opposite of what Max Weber would define of social action to be “the subjective meaning [of action] tak[ing into] account the behavior of others”. Inaction can be seen as a choice of indifference, especially when it comes from those who have the most freedoms to engage in such behavior. By choosing not to engage people who’ve spent time doing the work to interrogate, demand and produce action, one can slide into silent and passive acceptance of the hegemonic violence that we currently see rampaging Syria and the south side of Chicago, under the rule of Modhi and Macon, the intertwining nature of violence of Barack Obama and Osama bin Laden as agents of the spectacle and its child, terrorism. We won’t see it as any more than an “issue in a foreign land”, something to comment about on our neocolonialist devices of communication from our places of comfort within the belly of the beast. If we choose to do anything, the very least we should do is choose to listen to the people who our leaders are willing to print money to kill. Read and understand what they're saying and do everything you can to prevent their actions from being in vain.

“For if they find their state intolerable, but are too heavily oppressed to change it, they are simply pawns in the hands of larger powers, which, in such a context, are always unscrupulous, and when, eventually, they do change their situation [sic], we are menaced more than ever, by the vacuum that succeeds all violent upheavals,” by James Baldwin from The Fire Next Time.

mcc ( Like, this crate API is pretty complicated in terms of signatures and what you have to do to unwrap everything, but you supplied expressive sample code so that's fine
byMastodon archived copycurrent

Ah yeah, this is something I'm going to have to hammer down. Going to peek at some of the more highly used ones and muse on changing this crate's surface area.

mcc ( I dunno if I'm such a good judge of what is rust idiomatic but this looks pretty good to me. Could this allow a server app to let someone authenticate using their ActivityPub identity? That's something I'm interested in doing. Is there a reason base OAuth wasn't enough for that and it had to be extended?
byMastodon archived copycurrent

Heh, that works for me!

The spec kinda expands on this at but tl;dr: it removes the need for private stuff and makes the client ID public so you don't have to do client registration (but it also now forces that clients to be addressable — which could be an issue for headless/console apps but that's easy to work around if you do what Mastodon does with dynamic client registation).

This could if the the identity's info provides endpoints similar to OAuth2 — either an authorization and token endpoint or the singular endpoint that'd have all of that info and more (more at, I'm opting for this because it makes it easy to expose things like documentation about how it works, what kind of scopes are supported and the like).

Slowly going through the backlog of tickets for Sele. Still wishing Forgejo supported Webmention or some sort of Micropub endpoint for making things. That would be an interesting point to mash up (something like Bridgy but focused for code forges). Would make it easy for me to comment on them in a cross-platform way.

that's right @progrium, RelMeAuth (nice suggestion) works for any #OAuth + rel-me site, and enables auto-fallback with use of alternate identities for authentication: 1 user enters their site URL; 2 iterate through their outbound rel-me links; 3 if a rel-me destination is up, and rel-me links back to user's site, and has OAuth endpoint, then do OAuth authentication. Thus user links to their RelMeAuth profiles in preference order, and authentication code tries them in order. e.g. Twitter,, ... etc. No more OpenID server/delegate single point of failure, nor need to learn yet another XML format. - Tantek archived copycurrent

Just as I posted my potential success with Sele, I'm running into some SMTP errors on start (because it's checked for support on start, I guess I can remove that and instead opt for per-use testing but this felt more of a "check your shit, I won't run" kind of thing to reduce errors that I'll stick to).

I think I'm done with the base parts of Sele. There's still some parts that'll throw expections that I need to define guardrails around and I'm still annoyed with how WebAuthn absolutely requires a Web browser (not necessarily a user agent — whatever happened to those) for a neat integration. I'll figure that out later. For now, I'm going to start eating what I cook and cleaning it up around the rough edges. Ideally, the next post would be authorized by it!

I need to figure out how to have my debugger restart or reload whenever I change code. Doesn't matter what process I'm attached to. Extra points if I have it wait until after the target's been rebuilt. I know I can wire this together using nvim-dap and overseer.nvim. It's just not clear to me how to make tasks dependent on each other within overseer and tie that to dap.

Shit to do when I'm not doing anything else (like stressing about rent being due in a week).

I don't really like the explicit "reply" chain that's come to be thanks to Twitter's cementing of it. I'm more of a fan of the linking in text and reading from there. The benefit of the reply chain is that you can see all of the content forming the contextual umbrella at once. And when it comes to fast firing off of thoughts, it's more ergonomic than thumbing down a longer blog post or finding your laptop or computer to do so. I know that I'll be incorporating a way to immediately link to what I've posted in my composing tools for my site as well as fetching from my subscriptions because those are the things I'd be writing about.

The more I dig into Sele, the less likely I want to incorporate something like e-mail to be part of one's core identity. It does provide a failsafe in the event one loses their domain name (has happened to be more times than I've lost my email address) but e-mails can't be easily linked to and don't have explicit profiles that can be discerned from them. Profile discernment is important for portable identities (and allowing URLs to operate as a localized lookup system for the such makes things a bit easier).

byVectorized form of Jacky • posted archived copycurrent

What I'll do for now is treat them as URNs as I have implicit support for that, largely in prep to work with DIDs.

The more I dig into Sele, the less likely I want to incorporate something like e-mail to be part of one's core identity. It does provide a failsafe in the event one loses their domain name (has happened to be more times than I've lost my email address) but e-mails can't be easily linked to and don't have explicit profiles that can be discerned from them. Profile discernment is important for portable identities (and allowing URLs to operate as a localized lookup system for the such makes things a bit easier).

Making Rust binaries smaller by default

Have you ever tried to compile a helloworld Rust program in --release mode? If yes, have
you seen its binary size? Suffice to say, it’s not exactly small. Or at least it wasn’t small
until recently. This post details how I found about the issue and my attempt to fix it in Cargo.

Binary size analysis

I’m a member of the (relatively recently established)
#wg-binary-size working group,
which is trying to find opportunities to reduce the binary size footprint of Rust programs and libraries.
Since I also maintain the Rust benchmark suite, my main
task within the working group is to improve our tooling that measures and tracks the binary size of Rust programs.

As part of that effort, I recently added a new command to
the benchmark suite, which allows examining and comparing the sizes of individual sections and symbols of a Rust
binary (or a library) between two versions of the compiler.

The output of the command looks like this:

Output of the binary analysis command

While testing the command, I noticed something peculiar. When compiling the test binary in release mode
(using --release), the analysis command showed that there are (DWARF) debug symbols in the binary. My
immediate reaction was that I have a bug in my command and that I have to be compiling in debug mode by accident.
Surely Cargo wouldn’t add debug symbols to my binary in release mode by default, right? Right?

My reaction to Cargo's behavior

Anakin/Padmé meme about Cargo and debug symbols

I spent maybe 15 minutes looking for the bug before I realized that there is no bug in my code. There are debug
symbols in each Rust binary compiled in release mode by default, and this has been true for a long time. In fact,
there is an old Cargo issue (almost 7-year-old, to be precise) that
mentions this exact problem.

Why does this happen?

This is consequence of how the Rust standard library is distributed. When you compile a Rust crate, you don’t also
compile the standard library1. It comes precompiled, typically using Rustup, in the rust-std component.
To reduce download bandwidth2, it does not come in two variants (with and without debug symbols), but only in the
more general variant with debug symbols.

On Linux (and also other platforms), the debug symbols are embedded directly in the object files of the library itself
by default (instead of being distributed via
separate files). Therefore, when you link
to the standard library, you get these debug symbols “for free” also in your final binary, which causes binary size

This actually contradicts Cargo’s own documentation,
which claims that if you use debug = 0 (which is the default for release builds), the resulting binary will not contain
any debug symbols. But this is clearly not what happens now.

EDIT: Just to clarify, Cargo was putting the debuginfo of the Rust standard library into your program by default.
It was not including the debuginfo of your own crate in release mode by default.

Why is it a problem?

If you take a look at the binary size of a Rust helloworld program compiled in release mode on Linux, you’ll
notice that it has about ~4.3 MiB3. While it’s true that we have a lot more disk space
today than in the past, that’s still abhorrently much.

Now, you might think that this is a non-issue, because anyone who wants to have smaller binaries simply strips them.
That is a good point - in fact, after stripping the debug symbols from the mentioned helloworld binary4,
its size is reduced to merely 415 KiB, only about 10% of the original size. However, the devil is in the details

And defaults matter! Rust advertises itself as a language that produces highly efficient and optimal code, but this
impression isn’t really supported by a helloworld application taking more than 4 megabytes of space on disk. I can
imagine a situation where a seasoned C or C++ programmer wants to try Rust, compiles a small program in release
mode, notices the resulting binary size, and then immediately gives up on the language and goes to make fun of
it on the forums.

Even though the issue goes away with just a single strip invocation, it is still a problem in my view. Rust tries to
appeal to programmers coming from many different backgrounds, and not everyone knows that something like stripping
binaries even exists. So it is important that we do a better job here, by default.

Note that the size of the libstd debug symbols is around 4 megabytes on Linux, and this size is constant, so even
though for helloworld it takes ~90% of the size of the resulting binary, for larger programs its effect will be smaller.
But still, four megabytes is nothing to sneeze at, since it is included in every Rust binary built everywhere by default.

Proposing a change to Cargo

After I have realized that this is the default behavior of Cargo, I have actually remembered that I have just
rediscovered this exact issue perhaps for the third time already. I have just never really acted upon it before and then
always managed to forget about it.

This time, I was determined to do something about it. But where to start? Well, usually it’s not a bad idea to just
ask around on the Rust Zulip, so I did exactly that.
It turns out that I wasn’t the first person to ask that very same question, and that it came up multiple times over the years.
The proposed solution was to simply strip debug symbols from Rust programs in release mode by default, which would remove
the binary size bloat problem. In the past, this used to be blocked by the stabilization of strip support in Cargo,
but that has actually already happened back at the
beginning of 2022.

So, why wasn’t this proposal implemented yet? Were there any big concerns or blockers? Well, not really. When I
have asked around on Zulip, pretty much everyone thought that it would be a good idea. And while there were some
earlier attempts to do this, they haven’t been pushed through.

So, to sum up, it hasn’t been done yet because no one had done it yet :) So I set out to fix that. To test
if stripping by default could work, I created a PR to the compiler and started a perf benchmark. The binary size
results (for tiny crates) looked pretty good, so that gave me hope that the approach of stripping by default
could indeed work.

Funnily enough, this change also made compilation time of tiny crates (like helloworld) up to
2x faster
on Linux! How could that be, when we’re doing more work, by including stripping in the compilation process? Well,
it turns out that the default Linux linker (bfd)
is brutally slow5, so by removing the debug symbols from the final binary, we actually reduce the amount
of work the linker needs to perform, which makes compilation faster. Sadly, this has an observable effect only for really
tiny crates.

There is an ongoing effort to use a faster linker (lld) by default on Linux (again, defaults matter :smile:). Stay tuned!

After showing these results to the Cargo maintainers, they have asked
me to write down a proposal
on the original Cargo issue. In this mini-proposal, I have explained what change to the Cargo defaults I want to make,
how it could be implemented, and what are other considerations of the change.

For example, one thing that was noted is that if we strip the debug symbols by default, then backtraces of release builds
will… not contain any debug info, such as line numbers. That is indeed true, but my claim is that these have not been useful
anyway. If you have a binary that only has debug symbols for the standard library, but not for your own code, then even
though the backtrace will contain some line numbers from stdlib, it will not really give you any useful context (you
can compare the difference here).
There were also some implementation considerations, for example how to handle situations where only some of your target’s
dependencies request debug symbols. You can find more details in the

After I wrote the proposal, it went through the FCP process. The Cargo team members voted
on it, and once it was accepted after a
10-day waiting period designed for any last concerns (the FCP), I could implement
the proposal, which was actually surprisingly straightforward.

The PR has been merged
a week ago, and it is now in nightly! :tada:

The TLDR of the change is that Cargo will now by default use strip = "debuginfo" for the release profile
(unless you explicitly request debuginfo for some dependency):

# v This is now used by default, if not provided
strip = "debuginfo"

In fact, this new default will be used for any profile which does not enable debuginfo anywhere in its dependency
chain, not just for the release profile.

There was one unresolved concern about using strip on macOS, because it seems that there can be some
issues with it. The change has been in nightly for a week and
I haven’t seen any problems, but if this will cause any issues, we can also perform the debug symbols stripping selectively,
only on some platforms (e.g. Linux and Windows). Let us know if you find any issues with stripping using Cargo on macOS!


In the end, this was yet another case of “if you want it done, just do it”, which is common in open-source projects :)
I’m glad the change went through, and I hope that we won’t find any major issues with it and that it will be stabilized
in the upcoming months.

If you have any comments or questions, please let me know on Reddit.

  1. Unless you use build-std, which is
    however sadly still unstable. 

  2. While at the same time, ironically, increasing the size of Rust binaries on disk. 

  3. Tested with rustc 1.75.0

  4. For example with strip --strip-debug <binary>

  5. Although recently, there have been an effort to speed it up. 

• posted archived copycurrent