De-Rusted Git Fork: 'Git with WD-40 Applied'

Why is this VersionControl meme funny?

Level 1: The Clubhouse Rulebook

A group of friends has been building a treehouse with hammers and nails for twenty years. One day the leaders announce that from now on, everyone must also own a fancy new power tool — it's safer and most people already have one. One kid gets so annoyed that he photocopies the entire treehouse blueprint, erases every mention of the power tool, and starts his own treehouse next door with a sign that says "Now with rust remover!" It's funny because the new tool is literally called Rust, the spray that removes rust is a garage classic, and storming off to build your own copy is somehow both a tantrum and completely allowed by the clubhouse rules.

Level 2: Glossary for the Flame War

Fork: copying a project's source to develop it independently. Forks range from "weekend experiment" to "OpenOffice → LibreOffice, the original dies." The right to fork is the core freedom of open source.
Rust: a systems programming language whose compiler statically prevents most memory-corruption bugs (buffer overflows, use-after-free) that haunt C codebases. Beloved, evangelized, and resented in roughly equal measure.
Hard requirement: a dependency you cannot build without. Today Git builds with a C compiler — present on effectively every platform since the 1980s. Requiring Rust narrows that to platforms LLVM supports.
Toolchain: the full stack of compilers and build tools needed to produce a working binary. Adding a language doubles the toolchain surface.
XLibre: a contentious fork of the X11 display server, itself born from a governance dispute — making its developer a serial protest-forker.

The early-career lesson: language adoption decisions in infrastructure projects are never purely technical. They're about who can contribute, who can build, who gets left behind, and whose decades of expertise just got devalued. The code compiles either way; the community sometimes doesn't.

Level 3: The Fork Heard Round the Mailing List

The headline reads like satire and is, delightfully, journalism: "XLibre Dev Creates de-Rusted Git Fork — As Git prepares to make Rust a hard requirement for Git 3.0, this fork removes all Rust code and describes itself as 'Git with WD-40 applied'." Every layer of this is a chapter in the ongoing Rust culture war, the most reliable source of open-source drama since the systemd flame wars and the vim/emacs holy wars before it.

The background: the Git project — like the Linux kernel before it — began admitting Rust into a codebase that has been pure C since Linus wrote the first version in a caffeinated weekend in 2005. Making Rust a hard toolchain requirement for Git 3.0 is the line-in-the-sand moment: it means you can no longer build Git on any platform that lacks a Rust compiler. For mainstream platforms, irrelevant. For maintainers of obscure architectures, retro-Unix ports, and minimal bootstrap environments, it's an eviction notice. This exact argument played out in the kernel with enough heat to burn out several maintainers on both sides — memory safety and modern tooling versus toolchain portability, build-chain complexity, and the social friction of telling twenty-year C veterans to learn lifetimes.

The forker's pedigree completes the picture. XLibre is the protest fork of the X.org display server, created by a developer at odds with what he considers the freedesktop establishment's stewardship (and its drift toward Wayland). Protest-forking is the open-source equivalent of constitutional law: the right that legitimizes everything else. Usually the fork withers — maintaining a divergent copy of an actively developed project is a treadmill that accelerates forever, and ripping Rust out of Git means re-implementing or freezing every future feature the upstream writes in Rust. But the fork's existence is the argument: "your hard requirement isn't hard for me."

And then there's the name. "Git with WD-40 applied" is genuinely elite wordplay — WD-40 is the rust remover in every garage, so "de-Rusting" a codebase with it makes the pun operate at the literal, chemical, and programming-language levels simultaneously. The fact that WD-40 is technically a water displacer that mechanics will tell you is not a proper long-term lubricant — a temporary fix that feels great and solves nothing permanent — may be the most accurate part of the metaphor, intentional or not.

Description

A dark-mode X post from The Lunduke Journal (@LundukeJournal), timestamped 20:00 on 09/02/2026 with 3.1K views. The text reads: 'XLibre Dev Creates de-Rusted Git Fork - As Git prepares to make Rust a hard requirement for Git 3.0, this fork removes all Rust code and describes itself as "Git with WD-40 applied".' The humor hinges on the literal rust/Rust pun (WD-40 removes rust) and the very real culture war around Rust adoption in foundational C projects, with the XLibre developer (known for forking X.org in protest) now stripping Rust out of Git in defiance of the Git 3.0 toolchain requirement

Common Tags

Git Rust OpenSource VersionControl LanguageWars OpenSourceCulture TechTribalism WordplayPuns CFamilyLanguages

Comments

164

Anonymous ★ Top Pick Removing Rust to prevent corrosion - the first fork where the maintenance plan is literally a lubricant

Anonymous ★ Top Pick

Removing Rust to prevent corrosion - the first fork where the maintenance plan is literally a lubricant
@tuguzT 5mo

> denial > anger (we are here) > to be continued...
@azizhakberdiev 5mo

Can we have some de-vibecoded forks too?
1. @sysoevyarik 5mo
  
  Halal forks when
2. @Sumtala 4mo
  
  "De-rusted" implies that. Ai sucks at writing memory-safe c++ or c
  
  @azizhakberdiev 4mo
  
  To be honest, I suck too 👍
  
  @azizhakberdiev 4mo
  
  AI does as well, difference is it just doesn't debug 10 times before fixing it
@RiedleroD 5mo

knowing how XLibre went, this is gonna be hilarious
1. bur del lago 5mo
  
  how did xlibre go? i thought it was becoming a decent replacement
  
  @b7sum 5mo
  
  at the very least nvidia drivers are abi-incompatible
  
  @feedable 5mo
  
  fdo people tried to cancel both the project and the guy behind it
  
  @RiedleroD 5mo
  
  well, it was made by an ex-X11-contributor who was kicked from the team after multiple patches turned out to have caused major bugs and not really fixed anything. that and he's generally known to be a toxic asshole who uses his relative fame to spread hate and misinformation, e.g. covid conspiracy theories. so nobody who isn't the same kind of asshole wants to collaborate with him, meaning none of the bugs he introduces into the codebase get fixed
  
  bur del lago 5mo
  
  eh i kinda don’t care about who makes the software, no one does realistically speaking
  
  @b7sum 5mo
  
  debatable
  
  @RiedleroD 5mo
  
  sure, but a big project like X needs a big community of contributors and maintainers to function. as it stands, XLibre is a tiny team of people driven purely by hate for freedesktop et al
  
  @feedable 5mo
  
  so like most open software
  
  @feedable 5mo
  
  and not by hate of fdo; if fdo were not to ban them, the development would be upstream
  
  @RiedleroD 5mo
  
  not the big ones, usually. Think of GNOME, KDE, Linux, Wayland and Freedesktop in general, Xiph… most smaller programs don't need a big team because they're not that complex. but X was already too complex for the big team that existed before, so the little team that ks XLibre is just gonna shit the bed massively
  
  bur del lago 5mo
  
  how do we know they do it mostly because of hate? genuine question, hate-powered software?
  
  @RiedleroD 5mo
  
  last I looked it's all over their readme, wiki, social media posts, etc.
  
  @RiedleroD 5mo
  
  whatever this means, completely unprofessional
  
  @TheFloofyFloof 5mo
  
  don't forget the low effort breaking changes that were rejected by xorg, causing the fork
  
  @RiedleroD 5mo
  
  yup
@hoodiepaws 5mo

unfortunately i do get the sentiment behind this…
@hoodiepaws 5mo

rustc is a fucking 300 mb install
1. @TheFloofyFloof 5mo
  
  that is only for the dev environment
  
  @hoodiepaws 5mo
  
  you need to compile it if a prebuilt binary doesn’t exist for your env
2. @afdanilkin 5mo
  
  But GCC and Clang toolchains are also quite big, no? Is Rust one even bigger? And why is that, what causes it?
  
  @feedable 5mo
  
  because rust is basically garbage atop clang?
  
  @afdanilkin 5mo
  
  But then why requiring Clang is much different then requiring Rust, should not it be only something like 1.5 times more resources?
  
  @feedable 5mo
  
  you don't usually require clang
  
  @feedable 5mo
  
  a c++ project can be typically built with either gcc or clang, and a c project can be built with all kinds of toolchains
  
  @afdanilkin 5mo
  
  What do you require then? I feel like most of the C or C++ codebases are not fully portable and only build without source changes with some specific toolchains and their versions, and usually they are GCC, Clang or MSVC, and all of them are big?
  
  @feedable 5mo
  
  sure, but even so you can port them with minimal changes
  
  @feedable 5mo
  
  unlike rust for which no alternative toolchain even exist (and I'd argue can exist, for that matter)
  
  _ 5mo
  
  Well there are projects to. mrustc acts as a minimal Rust compiler to shorten bootstrap, and some people are writting a Rust frontend for GCC (in addition to the GCC backend for rustc)
  
  @feedable 5mo
  
  i've seen the code of both, and built both of them. Doomed to fail forever because still no spec. I've seen the only attempt at making a spec by ferrocine, which also failed
  
  _ 5mo
  
  Wdym it failed ?
  
  @feedable 5mo
  
  it's for rust 1.62 iirc, and even then it still had massive holes in the spec like "half the spec is just missing" holes, from what I remember
  
  _ 5mo
  
  It's still in progress or at least maintained, and they managed to certify their fork for use in industrial devices with that, so I wouldn't count that as a failure
  
  @afdanilkin 5mo
  
  I would say it might require a very significant effort, and it is proportional to the size of the project. And port to what, to some compiler tailored for tiny devices? Why you can not create such a minimal compiler for Rust then? Is it the fact that C compiler can be (mostly) single-pass, where as for Rust you need complex trait resolution which would run too slowly to be usable on these devices?
  
  _ 5mo
  
  There are quite some analyzes that are computationally complex and maybe tricky to get right. E.g. the borrow checker, the trait solver, match exhaustiveness
  
  @afdanilkin 5mo
  
  But from what I know, you only need a part of that to do code generation if your goal is just running programs in the language, you do not need full diagnostics for Clippy or rustc
  
  @feedable 5mo
  
  not necessarily, there are custom os'es and custom high performance architectures they run on
  
  @feedable 5mo
  
  because rust has no spec, and you can't be bug-for-bug compatible with rustc
  
  @afdanilkin 5mo
  
  I think there was some effort to write it (and I read some drafts found on the net), and C and C++ have a lot of implemetation-defined behaviour anyway
  
  @feedable 5mo
  
  so? it still doesn't mean that there is no spec
  
  @feedable 5mo
  
  "the spec is here but the implementation has to specify a couple of things" is different from "the spec is the behaviour of *our* implementation"
  
  @feedable 5mo
  
  and this part specifically is actively hostile towards alternative implementations
  
  @feedable 5mo
  
  and is also the reason why c++ while being way more complex, still has more implementations
  
  _ 5mo
  
  Also because it appeared before LLVM was developped, which makes it easy to target most architectures with a single implementation
  
  @feedable 5mo
  
  gcc existed for decades before that, and it is as easy to port gcc to another architecture as any other massive compiler
  
  @afdanilkin 5mo
  
  Why not try to work on the spec then, if it is the part that is missing?
  
  @feedable 5mo
  
  https://t.me/devs_chat/189441
  
  @feedable 5mo
  
  be my guest, convince the rust core team to make a spec, and make each rfc modify the spec
  
  @afdanilkin 5mo
  
  Hm, but that does not answer for me (maybe I missed something, sorry) why you can not work on it yourself, try to document how rustc works in a style of a spec (and report to the compiler devs if you find something really incoherent), or someone else do it, why you need to convience the core team (which maintains a quite stable compiler that does not break or change on whim) on something? I think afterwards, if you get some quality text, you could try to make it authorative, but it needs to exist first
  
  @feedable 5mo
  
  because rustc will move on by the time you get to a reasonable state (happened to ferrocene), and because no matter the quality of whatever you produce, it won't matter unless the infrastructure exists for non-rustc authors to contribute
  
  @afdanilkin 5mo
  
  Which infrastructure?
  
  @feedable 5mo
  
  say I have my implementation of rust (whatever that means). I want to extend the language. How do I do that without touching rustc?
  
  @afdanilkin 5mo
  
  You can just do it in private. Otherwise, you need to write and RFC in any case, and maybe make a concept implementation; people do it only with rustc, but if you have another sufficiently complete compiler, you might be able to do it there and drive language development forward this way. Why not? The RFC repo is separate, and proposals there I think only use rustc as current reality
  
  @feedable 5mo
  
  yes, and the repo is controlled entirely by the same people that develop rustc, and these are the people that decide which features actually go in, and alternative implementations have no leverage there
  
  @feedable 5mo
  
  (well, as much leverage as just a random guy submitting an rfc)
  
  @afdanilkin 5mo
  
  Not to the full extent, even might be some people in common. See https://rust-lang.org/governance/ There are separate "Leadership council", "Compiler team", "Language team" and others
  
  @feedable 5mo
  
  those are parts of the same organization
  
  @afdanilkin 5mo
  
  So what you actually say is a political claim of not having enough independence, and you would want Rust to have a spec maintained by some international body entirely separate as an organization from people working on an implementation?
  
  @feedable 5mo
  
  That woult be one way to achieve it, yes. The crucial things are again that the spec is treated as the source of truth (and therefore as the primary way to edit the language), and that implementers are treated as peers, rather than the current upstream/downstream relationship
  
  @afdanilkin 5mo
  
  What do you think about https://rustfoundation.org/ ? To be honest, I do not really fully understand how it works or what different groups of people are in charge of
  
  @feedable 5mo
  
  I do know the basics, but I don't really follow them closely anymore, since leaving rust scene
  
  @afdanilkin 5mo
  
  I still think that just working towards a good spec no matter the organization shortcomings might pave a way into that. Or creating other implementations. Then you would have easier time convincing people to have some independent governance using a spec and interests of multiple implementators, because they would already exists and so the problem of needing to have a fair way to make decisions would be more present and seem real
  
  @feedable 5mo
  
  Sure, yeah, it might, but then again ferrocene exists in however bad shape it is now, and no one at rustc is interested in adopting that as at least a base for further standardization efforts. And considering the crawlingly slow process of gccrs, which to my knowledge still can't resolve names properly because nobody actually knows how names are resolved in rust, a spec is already sorely needed now
  
  @afdanilkin 5mo
  
  I am not aware about any recent news (because I did not have time to read them for a while), what do you refer to when you talk about ferrocene being in a bad shape?
  
  @feedable 5mo
  
  No news, just that the spec is just not complete (or even nearly complete enough)
  
  @afdanilkin 5mo
  
  But again, this very specific issue can be resolved by anyone willing to take some time to research and document how Rust resolves names. And there probably is some algorithm for that that could not be changed or simplified without significant breakage, and if there is such a way, your PR, where you make it more principled and aligned with the description you wrote without any real downsides, would probably be welcome
  
  @feedable 5mo
  
  I mean, if that algo was stable and unchanging, I assume there wouldn't be any trouble in implementing it, but neither mrustc nor gccrs can do that properly even after years of trying (for the last 7 years in case of gccrs)
  
  @feedable 5mo
  
  And I remember that there were breaking changes to at least trait resolution when I was using rust
  
  @afdanilkin 5mo
  
  I think this is very rare, and I think rustc gives stronger guarantees (in theory and in practice) of compiling old code than GCC for C++
  
  @feedable 5mo
  
  I mean, GCC promises to compile all conformant code, and rust can't even theoretically promise that since there's nothing to base that off of
  
  @feedable 5mo
  
  (especially because you can't qualify a miscompilation as a bug under "all code compiled before must compile", but miscompilations are still being fixed
  
  @afdanilkin 5mo
  
  GCC has bugs and what is considered confomant changes over time, including when targeting the same standard version
  
  @feedable 5mo
  
  The difference still being that you as a user know what to expect (because everything else applies to rustc too)
  
  @afdanilkin 5mo
  
  But there is a succesful in practice effort to make Rust as backwards-compatible as possible, including by extensive testing using Crater, which ensures that the code doing this task produces some very (but maybe not completely) stable results across versions at least on code found in the real world. How do you explain that?
  
  @feedable 5mo
  
  Code still can compile but then behave differently
  
  @afdanilkin 5mo
  
  Not in a significant enough way to matter. You do not need to document the exact behaviour of the current version, but only "what it could have been" in a plausible release of rustc with the same stability guarantees. And you only need to do it once, and then you can align the implementation and make your description known by people, so that it is seen and updated when making future changes
  
  @feedable 5mo
  
  that's the part you can't do without a spec
  
  @afdanilkin 5mo
  
  You can, by applying your best consideration, by discussing with people and by checking compatibility using Crater, that is how it works today without a fully formal codification
  
  @feedable 5mo
  
  Yeah, I'm aware, but that's still not enough
  
  _ 5mo
  
  It seems it's already moving in the right direction, with goals such as "Develop the capabilities to keep the FLS up to date" and "Expand the Rust Reference to specify more aspects of the Rust language". IIRC they don't want to risk blocking RFCs on the spec, but were looking for a way to ensure changes to the language get reflected to the spec
  
  @afdanilkin 5mo
  
  And if "the spec is here, but contains way too many expilicitely unspecified points, and there are even more of them not even written that you need to implement anything remotely useful", so the spec is just some idealised dream and aspiration?
  
  @feedable 5mo
  
  do you actually know how many are there?
  
  @feedable 5mo
  
  and what are the reason they are there?
  
  @afdanilkin 5mo
  
  No, but the number of times I tried to look up what is "formaly" guarunteed about something, and I found that much was left unspecified, but there was some behaviour seen and practice and maybe written in the docs of the major compilers, is actually huge
  
  @feedable 5mo
  
  again, still tiny part of the language. The basic but not obvious stuff like name lookup, like overload resolution, like how (unfortunately not when) templates are instantiated, like the object model, is all specified and is relied upon widely. And the key here is not even that, but the fact that it is agreed upon by multiple implementations. I.e. the infrastructure to treat implementations as peers is already there
  
  @feedable 5mo
  
  This is important
  
  @feedable 5mo
  
  again, you need to convince people that a spec needs to exist before you make a spec, and people will need to accommodate the ongoing spec
  
  @afdanilkin 5mo
  
  But no, not really from what I know? To my knowledge, the specs for JavaScript, Web and even C itself were born from some standardization effort, and now we have some exemplary documents on which everyone collaborated and tries to maintain a common testsuite, but this happened without fully convincing first Microsoft or devs of countless small compilers to make Internet Explorer or their toolchains, and in some cases there was a near monopoly on these things?
  
  @feedable 5mo
  
  yes, those efforts arose from understanding that a spec needs to exist, for c and js and web
  
  @feedable 5mo
  
  internet explorer came way later, when web was already standardized
  
  @afdanilkin 5mo
  
  Not at all, not even close? Much or most of the early development of the web was driven by propriety work for IE and Netscape, specs came afterwards and documented these behaviors (or proposed improved versions of them), and traces of this are very present in current specs (with warnings "yes, it makes no sense, but it is this way because of some old implementation")
  
  @feedable 5mo
  
  these are just concessions to implementations, these do arise regardless
  
  @feedable 5mo
  
  they do occur even for existing standards, the c++ standard immediately comes to mind here
  
  @afdanilkin 5mo
  
  I tried to look it up. Here is a page for the specs I found: https://www.open-std.org/jtc1/sc22/wg14/www/projects Already, you need to pay 300 $ to get a real one, and not some "early draft". But let’s say I pick https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf There are 258 occurrences of "implementation-defined" and 185 ones of "unspecified". But what is really interesting is that there is an actual list, called J.3 and located starting at page 612 (linear numbering) of the file. I would want myself to read it at some point, because I find that it includes some really fundamental things (still unspecified); I think other sections nearby are also interesting
  
  @feedable 5mo
  
  Less than I expected tbh
  
  @DerKnerd 5mo
  
  still too much
  
  @feedable 5mo
  
  it's not
  
  @afdanilkin 5mo
  
  Maybe try to look into the pages I referenced above, I think an opinion informed by that would be interesting. I wanted to post some quotations or screenshots here, but the original text is way too long and is already good for the purpose of illustration
  
  @feedable 5mo
  
  I know about both of them, and I read the c standard many times already
  
  @afdanilkin 5mo
  
  That is interesting. Why did you do it, was it just for curiosity, or were you able to apply it to work on something (I do not think it is usual for people to read complete specs multiple time) and what was your experience?
  
  @feedable 5mo
  
  I ported gcc to a new arch
  
  @afdanilkin 5mo
  
  That’s really cool!
  
  @feedable 5mo
  
  (well, I usually read specs for the stuff I use, be it c or vulkan or js or spir-v, it's just useful in general)
  
  @afdanilkin 5mo
  
  I agree that it is a fun and useful activity and I also like to do it sometimes. But it does take a lot of time
  
  @afdanilkin 5mo
  
  This is only using keywords I found, with some occurrences in headings containing dozens of items, only for C, and a lot is just not mentioned, intentionally or not
  
  @afdanilkin 5mo
  
  But what is the point of having a spec to implement just from the information contained in it a working compiler, if you can not do it anyway and need to compare and match the behaviour of existing ones, because people rely on it everywhere and do not even know what the spec actualy guaruntees?
  
  @DerKnerd 5mo
  
  or, even worse, not being able to compile spec compliant code with the same outcome on two different compilers
  
  @feedable 5mo
  
  because resolving a couple of places with different semantics is better than guessing at the semantics of an entire language defined solely by the behaviour of one implementation which you do not control?
@hoodiepaws 5mo

that seriously kills a significant long tail of devices on which tools that require it can be compiled
1. @TheFloofyFloof 5mo
  
  is that bad? Do people really need to compile on tiny hardware?
  
  @hoodiepaws 5mo
  
  YES
@hoodiepaws 5mo

got an old, weird, or limited device? sorry, no prebuilt binary for your env, and no compiling bcs it’s all rust now, so you just can’t use git / other tool 🙃
1. @tema3210 5mo
  
  old weird environments gonna be supported by whom? also, why on earth anyone would get anything with less than 8GB ram nowadays?
  
  @hoodiepaws 5mo
  
  yeah. this is the problem with the world. not just in software. just make everything for the most common denominator. if it works on the latest macbook, it doesn’t need to work anywhere else. if it targets the straight white american male, it doesn’t need to include anyone else. etc etc.
  
  @tema3210 5mo
  
  Since when latest macbook is common denominator?
  
  @tema3210 5mo
  
  And since when white american man became common denominator? 😂
  
  @sysoevyarik 5mo
  
  "Most common denominator" have different meaning. It's not "x works for 70% users and that's enough", it's "x works for almost 100% users in cost of potential quality"
  
  @hoodiepaws 5mo
  
  since people like you saying things like this. you think the logic stops at ‘8gb ram’ bcs that’s your point of familiarity? sorry, someone else is deciding by similar logic to only support a more important audience that excludes you. i literally had my boss tell me ‘i just assume everyone has a macbook nowadays’ a week ago. it’s the exact same logic you follow. the world won’t change until people pull their heads out of the sand and actually think or care about circumstances they’re not personally familiar with.
  
  @hoodiepaws 5mo
  
  the whole point of the unix philosophy, once upon a time. no longer.
  
  @tema3210 5mo
  
  Less than 8gb is objectively outdated - got less? That's you problem, not me problem. Assumption of "all use mac"? - blatantly false: see market shares. BUT for your target audience it may be different
  
  _ 5mo
  
  For a laptop I can understand, but there are many embedded computer (things like Rasperry Pi) where that'd be overkill, but which would still benefit from various tools like git, ssh, vscode-server, python, you name it
  
  @DerKnerd 5mo
  
  May I be honest? I have an old Lenovo Yogabook, Atom x5, 4Gig RAM and I can do most stuff on it without issues
  
  @azizhakberdiev 5mo
  
  and that's why we don't just make assumptions, we research, gather data about devices
  
  @azizhakberdiev 5mo
  
  My internship was just full of that. I had to take surveys in person asking people what kind of phone they use, what kind of apps they prefer, I wasn't developing anything at that time
  
  @RiedleroD 5mo
  
  money
  
  @tema3210 5mo
  
  In absolute, yeah, but everything below the cheap segment - is sublinear in performace / cheapness. Up to the point where adding 100 dollars can give 1.5x perf
  
  @ner0xt 5mo
  
  phones and micro controllers
  
  @tema3210 5mo
  
  Not a single sould would run a fully blown compiler toolchain there - just bad fit for the task.
  
  @ner0xt 5mo
  
  welcome to the winlator/mobox community
  
  @TarasPushkar24 4mo
  
  All raspberries for example, or basically any embedded devices
2. @afdanilkin 5mo
  
  Is solving this by making Rust compatible with these devices possible?
3. @RealMrCactus 5mo
  
  You don't need rust installed to use the binary though????
  
  @TheFloofyFloof 5mo
  
  they are specifically talking about compiling git on e-waste
  
  @RealMrCactus 5mo
  
  I still don't see the problem
@hoodiepaws 5mo

unix tools have stopped being unix and become apple, in a way, and it saddens me. maybe i’m yelling at clouds idk
@Johnny_bit 5mo

2 questions: WHY RUST? Why not go with https://gameoftrees.org/ ?
1. @b7sum 5mo
  
  haven't expected anyone to mention this here
  
  @charachan 5mo
  
  likewise.
2. @sysoevyarik 5mo
  
  Zoomers created new shiny VCS again?
  
  @b7sum 5mo
  
  that's a project by openbsd
  
  @sysoevyarik 5mo
  
  And therefore it's not by zoomers (and especially not for zoomers)?
  
  @b7sum 5mo
  
  don't know hbu but i don't think it matters
@Johnny_bit 5mo

I mean just look at the logo...
@Johnny_bit 5mo

it's beautiful!
@dsmagikswsa 5mo

WD-40 ads detected
@hoodiepaws 5mo

holy shit i cannot believe i need to explain this.
1. @afdanilkin 5mo
  
  I think you actually do need to explain in a way: people need to listen more, that is for sure, but you also need to tell your needs in some way for people to know. I would be really interested, what are your use cases, and that of other people you know? I genuinely would never have thought that there is a significant amount of people for whom it is impossible to find 300 MB of space for an essential tool. I feel like there actualy is some baseline of what you can assume, because every single device on the market today has some level of capabilities (and weaker ones are just not made), so the only people who have something that not meet this level (in addition to people without anything at all) are one who use something they bought a long time ago and it did not break yet, no?
  
  @hoodiepaws 5mo
  
  https://t.me/devs_chat/189433
  
  @afdanilkin 5mo
  
  I guess it depends on what exactly you got, but compiling simple Rust should be possible on Raspberry Pi at least in some cases (probably most). The smallest amount of RAM the RP5 is sold with is 1 GB, and the smallest MicroSD card I see on the SanDisk website is 32 GB, so you could assume these for at least current generation devices of this type, no matter how cheap
  
  _ 5mo
  
  Raspberry Pis are still on the high end, I'd say 512 MB to 1 GB RAM is common. Some of these have on-board flash, in which case I think the capacity ranges from 4 to 32 GB
  
  @afdanilkin 5mo
  
  Yes. But in general, Raspberry PI and mobile phones are already near the lowest end of what anyone would use as a programming environment. You could of course find microcontrollers almost as weak as you wish, but they would be only used as embedded in something, and while you could use them for programming, actually setting up all the peripherals, UI, HID, etc would require a quite a bit of effort and money (and in this case you could have just bought something more fit for purpose)
@hoodiepaws 5mo

actually you know what i’ve decided i’m better off not. sorry. ignore this old person. everyone have a nice day etc
1. @stilriv 5mo
  
  why not, explain. if you have a low-end target it doesn't mean you have to compile on low-end host, cross compilation is already invented
bur del lago 5mo

if the software is good, that is. if it’s not, no one is gonna use it anyways
@nyxiereal 5mo

LMAOOOO
@nyxiereal 5mo

Of course this loser hates rust
1. @Johnny_bit 5mo
  
  Obviously oxidative degradation of materials is bad. Maintain your equipment and keep it rust free.

Use J and K for navigation

De-Rusted Git Fork: 'Git with WD-40 Applied'

Why is this VersionControl meme funny?

Level 1: The Clubhouse Rulebook

Level 2: Glossary for the Flame War

Level 3: The Fork Heard Round the Mailing List

Description

Categories

Common Tags

Comments

Related Memes

Merge Approved By Absence

Removing Claude From the Commit

Attackers Breach GitHub: How Did They Find an Uptime Window?