- Blog

Soft lock picking in real life

Clayton Ramsey — Fri, 27 Mar 2026 00:00:00 +0000

Last weekend, I played a fun little indie game called Real Life Soft Lock Picking. To play, just lose your phone, wallet, and keys all at the same time.

You will then be soft locked: despite every system in the world working as intended, you’ll be locked out of your home, unable to make any progress or even feed yourself. The only way out is by soft lock picking</a>, where you have to escape from a soft lock with a mix of cleverness and extraordinary patience.

Homeward bound</h2>
Once soft locked, your first problem is going to be finding some way to eat and sleep. Having locked your front door, you can’t get into your home. I live alone, so there were no spare copies of my home key except my landlord’s — but naturally, since I was phoneless, I had no way to contact him.
In any event, I lost all my things late on a Saturday night, so it would be unreasonable to expect my landlord to be available anyway. Once soft-locked, you are at the mercy of others; luckily, I had a friend who was willing to feed and house me until I got my stuff back. I’m left wondering about the people who aren’t as fortunate as me: people who have just moved, or who are traveling, or parents with kids that will all need food and shelter on short notice. Even when resources for them exist, you still need a way to find them and reach them, and without a phone, money, or transportation, it’s nearly impossible.
Catch twenty-two factor authentication</h2>
Even with the most pressing issues solved, you’re still soft locked. Your best lead to finding your stuff is using a tool like Find My to locate your phone and hoping that your phone is in the same place as all your other valuables. However, you probably won’t even be able to access Find My, since everything will be locked by two-factor authentication.
Back in the day, you only needed a username and password to sign into anything. Since passwords leak all the time</a>, most systems now demand that sign-ons from new devices pass two-factor authentication. Typically, this means that after trying the half-dozen or so passwords that you can remember, you will be greeted by a fun little message like this:

Let's make sure it's really you</h3>
[ ] [ ] [ ] [ ] [ ] [ ] 
We’ve sent a text to your phone with a 6-digit code. Enter that code above in the next 10 minutes to prove it’s really you.

Email me a code instead</a></li>
Contact support</a></li> </ul> </div> </blockquote>
This leaves you with a circular problem:

You need to access your accounts to locate your phone.</li>
You need to pass two-factor authentication to access your accounts.</li>
You need your phone to pass two-factor authentication.</li> </ul>
If I could get back into my apartment, I could at least use my laptop to try bypassing two-factor authentication. But after a morning texting him from a borrowed phone, my landlord wasn’t answering my texts, so that was right out.
After a few tries, I found that Apple’s authentication system is a fickle lover: sometimes, it will decide that your login attempt is cool enough to bypass two-factor authentication. With this in hand, I tracked down my phone (and all my other stuff) to the home of a confused gentlement who had accidentally grabbed the wrong bag.
Leaving keys around</h2>
In hindsight, it’s possible for a prudent person to leave themselves keys to make soft locks a little easier to pick. They can be physical, like leaving a real key with a friend, or metaphorical, like getting more ways to access your accounts. Maybe using just using Nix would have fixed this.
But expecting users to leave keys for themselves is a design mistake: Every backup method will eventuall fail. Users lose stuff and forget things all the time, and soft locking a user for that is just an exercise in automated cruelty. We make products to serve people, and not the other way around.

Garbage collection in Rust got a little better

Clayton Ramsey — Sun, 28 Dec 2025 00:00:00 +0000

Every language attempts to expand until it can be Java. Those languages which cannot so expand are replaced by ones which can.
some smart programmer, probably</a></footer> </blockquote>
A long time ago, I wrote a garbage collector</a>, called dumpster</code></a>, in Rust. If I may say so myself, it was a delightful garbage collector. However, I think it was imperfect, so I’m writing up this blog post to write about new improvements coming to dumpster</code> after two years in the wild. For this post, I selected just a couple of the cooler changes to dumpster</code>, mostly to share the joy of working on this project. I’ll try my best to explain the changes for those without much expertise in garbage collection and brag a bit about how cool they are.
Recap episode</h2>
To summarize the 6,000-word article that I wrote last time, dumpster</code> is a garbage collection library with an emphasis on performance, flexibility, and correctness. dumpster</code> exposes a Gc<T></code> type, similar to the Rust standard library’sRc</code></a> or Arc</code></a>, that wraps some garbage-collected value of type T</code>. A Gc</code> is a garbage-collected pointer, so users can fearlessly create reference cycles in their code. For instance, a user could make a struct that contains a garbage-collected reference to itself, without causing the same memory leaks arising from using Rc</code> for the same goal.
use std::cell::OnceCell; use dumpster::{Trace, unsync::Gc}; #[derive(Trace)] struct Foo { /// pointer to this same struct! this: OnceCell<Gc<Self>>, } let foo = Gc::new(Foo { this: OnceCell::new() }); foo.this.set(foo.clone()); // Were `foo` in an `Rc`, this would leak! dumpster::unsync::collect(); // still collects foo! </code></pre> You might not think that a garbage collector is useful in Rust, but it shows up in surprisingly many places. I personally got into garbage collection while implementing a language runtime: Rust is a great language for writing interpreters, but unlike Go or Java, you can’t rely on the language runtime to do garbage collection for you. Likewise, it’s a big help in graph algorithms, which can have pointer spaghetti going all over the place.
All in on dynamic dispatch</h2>
To collect cycles, dumpster</code> needs some way of inspecting every garbage collected value for any Gc</code>s that they may contain. We achieve our inspection by forcing garbage-collected values to implement a special trait, called Trace</code>. Trace</code> borrows thevisitor pattern</a>: every time we want to do something to a garbage-collected value, we ask that value to accept a visitor, delegate that visitor to its fields, recursively going down until it reaches a Gc</code>.
// details differ from the real implementation, // but this is close enough pub trait Trace { fn accept<V: Visitor>(&self, visitor: &V); } // `dumpster` defines visitors to access fields pub trait Visitor { fn visit<T: Trace>(&self, gc: &Gc<T>); } </code></pre> Previously, Trace</code> was not dyn</code>-compatible</a>. Even though dumpster</code> supported dynamically-sized types inside of a Gc</code>, we still couldn’t stow a trait object inside a Gc</code>, such as with Gc<dyn Any></code>. I find this aesthetically displeasing: we’ve already filled dumpster</code> with Java-isms, so we should find some way to go all the way on dynamic dispatch. The heart of the problem is that, in Rust, generics and dynamic dispatch don’t mix. When we write <V: Visitor></code> in the signature for accept</code>, we declare that we must make a new implementation for accept</code> for every type V</code> that calls it. That means everything has to be pinned down at compile time, so we can’t just erase type information as dyn</code>-compatibility requires. However, Rust does polymorphism like this for good reasons: having that compile-time information enables loads of optimizations. So, how do we manage to keep the same flexibility and performance as compile-time generics while gaining the ability to use dynamic dispatch? I didn’t figure this out, but a brilliant contributor to the project by the name of bluurryy</a> did. They had a great insight: we can pin down an exact list of every Visitor</code> that dumpster</code> requires for a garbage collected value inside of our library, and with a little trait magic, we can force client code to accept our visitors without ever knowing what they are. This means that we still get the compile-time performance guarantees, but since the list of visitors is fixed, it’s possible to make Trace</code> dyn</code>-compatible. To do so, bluurryy</code> broke Trace</code> into a few traits, augmenting Trace</code> with TraceWith<V></code> and TraceWithV</code>. Client code must implement TraceWith<V></code> for all V: Visitor</code>, since it’s impossible for them to implement Trace</code> or TraceWithV</code> directly. Internally, TraceWithV</code> has a list of all the possible visitors. // again, papering over some details // main public-facing trait pub trait Trace: TraceWithV {} // clients must implement this instead of Trace pub trait TraceWith<V> { fn accept(&self, visitor: &V); } mod secret { // can update this list of requirements to add more visitors pub trait TraceWithV: TraceWith<Visitor1> + TraceWith<Visitor2> {} impl<T> TraceWithV for T where T: TraceWith<Visitor1> + TraceWith<Visitor2> {} } struct Visitor1; impl Visitor for Visitor1 { /* ... */ } struct Visitor2; impl Visitor for Visitor2 { /* ... */ } </code></pre> Since TraceWithV</code> and Trace</code> have no generics in any of their types or methods, Trace</code> is dyn-compatible, so it’s finally possible to write (admittedly clunky) dynamic-dispatched code. use dumpster::{ unsync::{coerce_gc, Gc}, Trace, }; trait MyTrait: Trace {} impl<T: Trace> MyTrait for T {} let gc: Gc<i32> = Gc::new(5); let gc: Gc<dyn MyTrait> = coerce_gc!(gc); </code></pre>Making cyclic data structures</h2> If you thought my very first example, creating a self-referential Gc</code>, was a little clunky, then you’re not alone! I find it a total pain everywhere from tests to documentation to application code to blog posts. In order to have a self-reference, each garbage-collected value must contain some sort of interior mutability to smuggle a pointer into itself. Since the simplest and most common use case is for a garbage-collected value to keep a pointer to itself, there should be an easy way to construct a simple self-referential Gc</code> like Foo</code> above. Creativity is overrated. There’s already a function that does that in the standard library, called Rc::new_cyclic</code></a> (or Arc::new_cyclic</code></a>). In a new_cyclic</code> function, client code can construct a Gc</code> by passing in a helper function that builds a value out of a pointer to itself. For example, we could rewrite the construction for Foo</code> using a straightforward call to new_cyclic</code>. use std::cell::OnceCell; use dumpster::{Trace, unsync::Gc}; #[derive(Trace)] struct Foo { /// pointer to this same struct! this: Gc<Self>, } let foo = Gc::new_cyclic(|this| Foo { this }); </code></pre> However, the standard library’s approach (passing around a separately-typed weak pointer) won’t work for Gc</code>s. The whole point of a Gc</code> is that we guarantee that it is (almost) always valid, even in the face of cycles, so we can’t just make up a WeakGc</code> type. I chose to solve my problems by reusing the one good idea I had in this project: abusing the visitor pattern. When client code calls new_cyclic</code> with some constructor f</code>, we can lie: instead of having the this</code> pointer actually point to an allocation, we’ll just pass in a garbage, dead Gc</code>. This dead Gc</code> will contain a garbage sentinel value instead of a pointer, so it doesn’t actually point to a value yet. Then, once the value has been constructed and f</code> returns, we’ll use our visitor to rehydrate every dead Gc</code> into a live one. Since we only rehydrate dead Gc</code>s, containing garbage values, the client code can include other, perfectly valid Gc</code>s in their returned value without anything breaking. This approach is sound since we can just crash the program if client code attempts to dereference a dead Gc</code>. At first, I thought this was only possible in my single-threaded unsync</code> implementation of Gc</code>. I had assumed that malicious client code could smuggle out a reference to the value returned from f</code>, making the rehydration process for Gc</code>s into Undefined Behavior due to the shared-xor-borrow rule. However, the Rust type system came to save me once again: since returning a value from f</code> is a move, it necessarily invalidates all borrows against the newly-constructed value. Since the implementation of Trace</code> expressly forbids weird pointer types from being stored in a Gc</code>, it’s impossible for client code to observe the rehydration process. Breadheel</h2> There were actually a lot of big changes to dumpster</code> in the last two years! I have only finite energy and time, so I’ve highlighted just two of the coolest ideas. I had a lot of fun implementing all this, and there’s still a lot more to do! For instance, I want to see if I can get niche-optimization for zero-overhead Option<Gc></code> and, of course, I always want to crank out extra performance. But for now, I think this is a good place for dumpster</code> to be: it’s fast, powerful, and as always a little cute.
My second year of grad school: reflections Clayton Ramsey — Sun, 17 Aug 2025 00:00:00 +0000 Two years of Ph.D. study have made me twice as smart as before! Well, not really. But I’ve still grown a lot, and I’ve added up a lot of achievements. Admittedly, there hasn’t been much outward change, since I’ve no more publications than last year, but I think I’m in a far better shape than the last time</a> I wrote a reflection. I’ve pushed my prior work in front of loads of eyeballs, especially since I presented it at a number of places, from on campus at Rice to two different workshops at ICRA. Meanwhile, my long-running ongoing project in task in motion planning is finally wrapping up, so I am now getting ready to publish a paper requiring many-times more work than my first project. More importantly, though, I think I’ve grown and developed as a researcher and a programmer. Establishing my own direction</h2> This year, my personal theme has been establishing independence. In the fall, I checked in regularly with my mentors-cum-collaborators Wil</a> and Zak</a>, as well as with my doctoral advisor, Lydia, for tactical direction; now, I pick out my own directions and fire off progress updates for vibe-checks. To toot my own horn: I think this was a big success! Last year, I feared I wasn’t cut out for it; I am quite proud of my growth here. Admittedly, my research strategies are pretty weird: I’ve no tolerance eating frogs, so I establish direction via, essentially, play. I pick my tools, problems, and approaches mostly based on personal excitement; the net result is that I optimize myself into a niche of things that I like. Day-to-day, this means I spend my time thinking about data structures and hardware acceleration; there is a tiny monkey in my brain pleased only when millisecond counts in my benchmarks go down. I do not know how long this approach will last or how far it will take me, but for now it is excellent for my morale. Getting blocked</h2> I struggle to maintain focus, even on things I like working on. It’s worst when I’m blocked: I encounter a problem that I don’t fully understand, requiring at the a context-switch into some other documentation or a coworker’s help. Each blockage is an off-ramp to go do something else; I’d suddenly find myself checking my email, bothering an intern, or just playing with an easier project. Likewise, I’m introverted and dislike asking others for help, so I wait far too long to seek help when I get stuck — if I do at all. The net result is blocked projects stay blocked until I work up the willpower to work on them again. The longer a project spends in a blocked state, the worse it gets, since making progress now requires facing my own non-progress. Like any properly maladjusted grad student, I stake my happiness on my work progress, so a slow-moving project is also a depressing project. Continuing from a blocked state then requires not only the standard willpower for working on something hard or socially stressful but also the emotional wherewithal to engage with a project that already makes me feel bad. The net result is a vicious cycle: I fall behind, feel bad about it, don’t continue, and fall further behind. Under normal conditions I can manage this cycle well enough, but this year has been harder for me. My research work is much more independent now, so I find I have less immediate feedback; if I want tactical advice, I usually have to ask for it. More personally, my mother’s third and likely final cancer diagnosis has demanded that I spend much of my free time with her, about a three hour drive away from home. Sometimes I feel that I spend my weeks carting between sleep and work and mom in a dreamlike fug. Going to work, staying focused, and even doing things I normally find fun are all just a little harder now; the net result is that my own productivity is far more variable than it used to be. My internship at JSC during the summer was probably the worst case of non-progress that I’ve had since, frankly, middle school. My mom’s health issues were reaching a head, and I burned an hour commuting each way to the outskirts of Houston to spend all day in a windowless concrete box; such conditions are not conducive to clarity of focus or concentration of will. By the end, I felt I had next to nothing to show for the summer’s work, especially compared to my peers. Were I older and wiser, perhaps I could conclude with a motivating tale of my resourcefulness and growth; however, the astute reader will note the publication date. I’m writing just after the summer has ended, so I’m fresh off of that experience. I have some cause for hope though; during the school year, my commute becomes a ten-minute bike ride to a office with a window. If my surroundings can tank my productivity, then maybe my surroundings can also revive them. Having fun with my tools</h2> On to more exciting topics! My current work is in task and motion planning; the details are irrelevant to this post, but in short, solving such planning problems requires gluing a plethora of dependencies together. Each dependency special in its own way, making dependency management an exercise in organized chaos. The worst offender was task planning: my task planner was a Python script that takes in file-paths with problem definitions, then sets off a chain of dominoes converting the problem into an intermediate representation (another file), and finally firing off a separate search binary compiled from C++ to generate an infinite stream of solutions. Naturally, there is no way to inspect the process, nor to programmatically request just one solution in a stream, so I wrote a hacky wrapper using inotify</code> to inspect the planner’s output in /tmp</code> and send IPC signals to stop and start the planner process group whenever I needed another task plan. Of course, any mistake in this management would fill my hard drive with nine hundred gigabytes of task plans. If I don’t catch it, no problem! My desktop environment will notify me by crashing on out-of-storage errors. After a few months mired in build scripts and template errors, I just gave up. I rewrote the entire motion planning framework in Rust, and eventually rewrote my task planners too, then forked my simulation tools to make compile times faster. On the whole, the rewrites of all my dependencies spanned maybe ten thousand lines of code, and took me a month or two of cumulative effort spread across the fall semester (and my winter break). Conventional wisdom dictates that one should never do a total rewrite of their software, but in my case, it was a great choice! Rewriting the motion planner gave me finer control over the planner (good for building on top of it), while rewriting the task planner yielded an order-of-magnitude speedup. The difference is stark: I spent much of the fall of this year spinning my wheels, with very little clue of what to do and how to do it. Once I started rewriting my entire project in Rust, I had a second wind: working on the project was way more fun, so I was able to move much more quickly. I’ve come to think of my own research as a sort of play: the more fun I’m having, the more progress I make, and the more progress I make, the more fun I’m having. A spot of hope?</h2> After over a year of work, I finally have a research project chugging along (mostly) smoothly. I’m targeting a publication deadline in mid-September, so I have a lot of writing to do, but I am confident that I can make it. Look out for a blog post when the project is (eventually) done!! Personally, I feel that this has shown a lot of growth for me. I can now set my own research directions, but I still struggle with motivation and time management. In all, though, I’m looking forward to new projects building off my current work, and also maybe to getting sidetracked and building some weird tools. I'd rather read the prompt Clayton Ramsey — Sat, 03 May 2025 00:00:00 +0000 When I grade students’ assignments, I sometimes see answers like this: Utilizing Euler angles for rotation representation could have the following possible downsides: Gimbal lock: In certain positions, orientations can reach a singularity, which prevents them from continuously rotating without a sudden change in the coordinate values.</li> Numeric instability: Using Euler angles could cause numeric computations to be less precise, which can add up and produce inaccuracies if used often.</li> Non-unique coordinates: Another downside of Euler angles is that some rotations do not have a unique representation in Euler angles, particularly at singularities.</li> </ul> The downsides of Euler angles make them difficult to utilize in robotics. It’s important to note that very few implementations employ Euler angles for robotics. Instead, one could use rotation matrices or quaternions to facilitate more efficient rotation representation. [Not a student’s real answer, but my handmade synthesis of the style and content of many answers] </blockquote> You only have to read one or two of these answers to know exactly what’s up: the students just copy-pasted the output from a large language model, most likely ChatGPT. They are invariably verbose, interminably waffly, and insipidly fixated on the bullet-points-with-bold style. The prose rarely surpasses the sixth-grade book report, constantly repeating the prompt, presumably to prove that they’re staying on topic. As an instructor, I am always saddened to read this. The ChatGPT rhetorical style is distinctive enough that I can catch it, but not so distinctive to be worth passing along to an honor council. Even if I did, I’m not sure the marginal gains in the integrity of the class would be worth the hours spent litigating the issue. I write this article as a plea to everyone: not just my students, but the blog posters and Reddit commenters and weak-accept paper authors and Reviewer 2. Don’t let a computer write for you! I say this not for reasons of intellectual honesty, or for the spirit of fairness. I say this because I believe that your original thoughts are far more interesting, meaningful, and valuable than whatever a large language model can transform them into. For the rest of this piece, I’ll briefly examine some guesses as to why people write with large language models so often, and argue that there’s no good reason to use one for creative expression. Why do people do this?</h2> I’m not much of a generative-model user myself, but I know many people who heavily rely upon them. From my own experience, I see a few reasons why people use such models to speak for them. It doesn’t matter. I think this belief is most common in classroom settings. A typical belief among students is that classes are a series of hurdles to be overcome; at the end of this obstacle course, they shall receive a degree as testament to their completion of these assignments. I think this is also the source of increasing language model use in in paper reviews</a>. Many researchers consider reviewing ancillary to their already-burdensome jobs; some feel they cannot spare time to write a good review and so pass the work along to a language model. The model produces better work. Some of my peers believe that large language models produce strictly better writing than they could produce on their own. Anecdotally, this phenomenon seems more common among English-as-a-second-language speakers. I also see it a lot with first-time programmers, for whom programming is a set of mysterious incantations to be memorized and recited. I think this is also the cause of language model use in some forms of academic writing</a>: it differs from the prior case with paper reviews in that, presumably, the authors believe that their paper matters, but don’t believe they can produce sufficient writing. There’s skin in the game. This last cause is least common among individuals, but probably accounts for the overwhelming majority of language pollution on the Internet. Examples of skin-in-the-game writing include astroturfing, customer service chatbots, and the rambling prologues found in online baking recipes. This writing is never meant to be read by a human and does not carry any authorial intent at all. For this essay, I’m primarily interested in the motivations for private individuals, so I’ll avoid discussing this much; however, I have included it for sake of completeness. Why do we write, anyway?</h2> I believe that the main reason a human should write is to communicate original thoughts. To be clear, I don’t believe that these thoughts need to be special or academic. Your vacation, your dog, and your favorite color are all fair game. However, these thoughts should be yours: there’s no point in wasting ink to communicate someone else’s thoughts. In that sense, using a language model to write is worse than plagiarism. When copying another person’s words, one doesn’t communicate their own original thoughts, but at least they are communicating a human’s thoughts. A language model, by construction, has no original thoughts of its own; publishing its output is a pointless exercise. Returning to our reasons for using a language model, we can now examine them once more with this definition in mind. If it’s not worth doing, it’s not worth doing well</h3> The model output in the doesn’t-matter category falls under two classes to me: the stuff that actually doesn’t matter and the stuff that actually does matter. I’ll start with the things that don’t matter. When someone comments under a Reddit post with a computer-generated summary of the original text, I honestly believe that everyone in the world would be better off had they not done so. Either the article is so vapid that a summary provides all of its value, in which case, it does not merit the engagement of a comment, or it demands a real reading by a real human for comprehension, in which case the summary is pointless. In essence, writing such a comment wastes everyone’s time. This is the case for all of the disposable uses of a model. Meanwhile, there are uses which seem disposable at a surface-level and which in practice are not so disposable (the actually-does-matter category). I should hope that the purpose of a class writing exercise is not to create an artifact of text but force the student to think; a language model produces the former, not the latter. For paper reviewers, it’s worse: a half-assed review will produce little more than make-work for the original authors and tell the editor nothing they didn’t already know. If it’s worth doing, it’s worth doing badly</h3> I’ll now cover the opposite case: my peers who see generative models as superior to their own output. I see this most often in professional communication, typically to produce fluff or fix the tone of their original prompts. Every single time, the model obscures the original meaning and adds layers of superfluous nonsense to even the simplest of ideas. If you’re lucky, it at least won’t be wrong, but most often the model will completely fabricate critical details of the original writing and produce something completely incomprehensible. No matter how bad any original human’s writing is, I can (hopefully?) trust that they have some kind of internal understanding to share; with a language model, there is no such luck. I have a little more sympathy for programmers, but the long-term results are more insidious. You might recall Peter Naur’s Programming as Theory Building</cite>: writing a sufficiently complex program requires not only the artifact of code (that is, the program source), but a theory</dfn> of the program, in which an individual must fully understand the logical structure behind the code. Vibe coding; that is, writing programs almost exclusively by language-model generation; produces an artifact with no theory behind it. The result is simple: with no theory, the produced code is practically useless. In Naur’s terms, such a program is dead</dfn>; in our case, it’s stillborn. It should come as no surprise that nearly every vibe-coded app on the Internet struggles with security issues; look no further than the vibe-coded recipe app that leaks its OpenAI keys</a>. Every time one generates code by prompt, they create a new stillborn program; vibe coding is the art of stitching together their corpses into Frankenstein’s monster. An annotated exercise</h2> As an experiment, I copied the thesis statement of this essay into Google Gemini and prompted it to complete the essay. Below the spoiler is its complete response. The complete prompt and output.</summary> Prompt: The following is an introduction to a short essay which I have written. Complete the essay by writing 2 short paragraphs. I write this article as a plea to everyone: not just my students, but the blog posters and Reddit commenters and weak-accept paper authors and Reviewer 2. Don’t let a computer write for you! I say this not for reasons of intellectual honesty, or for the spirit of fairness. I say this because I believe that your original thoughts are far more interesting, meaningful, and valuable than whatever a large language model can transform them into. For the rest of this piece, I’ll briefly examine some guesses as to why people write with large language models so often, and argue that there’s no good reason to use one for creative expression. </blockquote> Output: It’s fascinating to consider why so many are turning to large language models for writing. Perhaps it stems from a desire for efficiency, a wish to quickly generate text without the perceived effort of crafting each sentence. The allure of instant output can be strong, especially in a world that often prioritizes speed. For students facing deadlines, or blog posters needing content, the temptation to shortcut the writing process might feel overwhelming. There could also be a sense of insecurity, a feeling that one’s own writing isn’t “good enough” and that a language model can somehow elevate it. This might be particularly true for those navigating the often critical world of academic reviews or the sometimes harsh landscape of online commentary. However, this reliance on artificial intelligence fundamentally misunderstands the very essence of creative expression. Your individual voice, shaped by your unique experiences, perspectives, and even your struggles to articulate an idea, is what makes your writing resonate. A language model, trained on vast datasets of existing text, can only ever produce a pastiche, a reflection of what has already been said. It lacks the spark of genuine insight, the unexpected turn of phrase that comes from wrestling with a concept until it becomes your own. To surrender your voice to an algorithm is to diminish the potential for true connection and the profound satisfaction of communicating your own original thoughts to the world. </blockquote> </details> The resulting text is, put plainly, boring. In its 234-word output, the model produces merely a lengthy rehash of the same prompt. Tonally, it provides no more than sweeping and pointless generality, and any points earned for its brobdingnagian vocabulary are immediately lost to its total lack of taste in using it. For example, consider the following sentence: Perhaps it stems from a desire for efficiency, a wish to quickly generate text without the perceived effort of crafting each sentence. </blockquote> Gemini has produced a big sentence for a small thought. I can trivially cut two-thirds of it and remove nothing of substance: Perhaps it stems from a desire for efficiency. </blockquote> With some care, I can trim it a little more. Perhaps people do it for efficiency. </blockquote> So, in short, a language model is great for making nonsense, and not so great for anything else. Just show me the prompt</h2> I now circle back to my main point: I have never seen any form of create generative model output (be that image, text, audio, or video) which I would rather see than the original prompt. The resulting output has less substance than the prompt and lacks any human vision in its creation. The whole point of making creative work is to share one’s own experience - if there’s no experience to share, why bother? If it’s not worth writing, it’s not worth reading. How I make figures Clayton Ramsey — Fri, 02 May 2025 00:00:00 +0000 As a grad student, I have to give a lot of presentations, and all those presentations have to look good. Inevitably this means that I have to make a lot of pictures. This is a short little post about how I make “explanatory” figures: diagrams and models and such. I prefer to make my own figures, since I’m always disappointed to see AI-generated stock photos. To be honest, I’d rather they just tell me what prompt they gave to the model, rather than the output. In some presentations I might also borrow figures from others’ work (with attribution, of course), but most of the time, I just make my own. For this article, I’ll walk through the creation process for one figure. The details aren’t super important, but in this case it’s a search tree, a la Monte Carlo Tree Search. Sketches</h2> </div> </div> </div> Hand-sketched figures, before and after touching them up.</figcaption> </figure> My figures usually start life as sketches done in pen in a notebook. If I can find one, I’ll use graph paper to make things line up nicely on a grid. Usually, I don’t have it, so I just draw it on ordinary college-ruled stuff. I then take a picture of the sketch with my phone, and fiddle with my phone’s built-in color adjustment until it’s all just black and white. Sometimes this is the end state of my figure, since I often don’t need perfectly gorgeous slides, and I quite like the scrappy look of the doodles. The diagram after tracing.</figcaption> </figure> If I want something just a little bit sharper than the scanned drawing, but still a little scrappy, I’ll throw the scanned drawing into Inkscape and have it trace the figure. This gives cleaner lines and yields scalable figures, but sometimes it smudges things up. Nicer figures</h2>

- Blog

Soft lock picking in real life

Let's make sure it's really you</h3> [ ] [ ] [ ] [ ] [ ] [ ] </p> We’ve sent a text to your phone with a 6-digit code. Enter that code above in the next 10 minutes to prove it’s really you.</p>

Garbage collection in Rust got a little better

My second year of grad school: reflections

I'd rather read the prompt

How I make figures