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

Anonymous ★ Top Pick

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

Anonymous

Git finally found a merge conflict that can be resolved with aerosol lubricant.

@tuguzT 6mo

> denial > anger (we are here) > to be continued...

@azizhakberdiev 6mo

Can we have some de-vibecoded forks too?

@sysoevyarik 6mo

Halal forks when
@Sumtala 6mo

"De-rusted" implies that. Ai sucks at writing memory-safe c++ or c
1. @azizhakberdiev 6mo
  
  To be honest, I suck too 👍
  
  @azizhakberdiev 6mo
  
  AI does as well, difference is it just doesn't debug 10 times before fixing it

@RiedleroD 6mo

knowing how XLibre went, this is gonna be hilarious

bur del lago 6mo

how did xlibre go? i thought it was becoming a decent replacement
1. @b7sum 6mo
  
  at the very least nvidia drivers are abi-incompatible
2. @feedable 6mo
  
  fdo people tried to cancel both the project and the guy behind it
3. @RiedleroD 6mo
  
  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 6mo
  
  eh i kinda don’t care about who makes the software, no one does realistically speaking
  
  @b7sum 6mo
  
  debatable
  
  @RiedleroD 6mo
  
  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 6mo
  
  so like most open software
  
  @feedable 6mo
  
  and not by hate of fdo; if fdo were not to ban them, the development would be upstream
  
  @RiedleroD 6mo
  
  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 6mo
  
  how do we know they do it mostly because of hate? genuine question, hate-powered software?
  
  @RiedleroD 6mo
  
  last I looked it's all over their readme, wiki, social media posts, etc.
  
  @RiedleroD 6mo
  
  whatever this means, completely unprofessional
  
  @TheFloofyFloof 6mo
  
  don't forget the low effort breaking changes that were rejected by xorg, causing the fork
  
  @RiedleroD 6mo
  
  yup

@hoodiepaws 6mo

unfortunately i do get the sentiment behind this…

@hoodiepaws 6mo

rustc is a fucking 300 mb install

@TheFloofyFloof 6mo

that is only for the dev environment
1. @hoodiepaws 6mo
  
  you need to compile it if a prebuilt binary doesn’t exist for your env
@afdanilkin 6mo

But GCC and Clang toolchains are also quite big, no? Is Rust one even bigger? And why is that, what causes it?
1. @feedable 6mo
  
  because rust is basically garbage atop clang?
  
  @afdanilkin 6mo
  
  But then why requiring Clang is much different then requiring Rust, should not it be only something like 1.5 times more resources?
  
  @feedable 6mo
  
  you don't usually require clang
  
  @feedable 6mo
  
  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 6mo
  
  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 6mo
  
  sure, but even so you can port them with minimal changes
  
  @feedable 6mo
  
  unlike rust for which no alternative toolchain even exist (and I'd argue can exist, for that matter)
  
  _ 6mo
  
  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 6mo
  
  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
  
  _ 6mo
  
  Wdym it failed ?
  
  @feedable 6mo
  
  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
  
  _ 6mo
  
  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 6mo
  
  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?
  
  _ 6mo
  
  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 6mo
  
  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 6mo
  
  not necessarily, there are custom os'es and custom high performance architectures they run on
  
  @feedable 6mo
  
  because rust has no spec, and you can't be bug-for-bug compatible with rustc
  
  @afdanilkin 6mo
  
  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 6mo
  
  so? it still doesn't mean that there is no spec
  
  @feedable 6mo
  
  "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 6mo
  
  and this part specifically is actively hostile towards alternative implementations
  
  @feedable 6mo
  
  and is also the reason why c++ while being way more complex, still has more implementations
  
  _ 6mo
  
  Also because it appeared before LLVM was developped, which makes it easy to target most architectures with a single implementation
  
  @feedable 6mo
  
  gcc existed for decades before that, and it is as easy to port gcc to another architecture as any other massive compiler
  
  @afdanilkin 6mo
  
  Why not try to work on the spec then, if it is the part that is missing?
  
  @feedable 6mo
  
  https://t.me/devs_chat/189441
  
  @feedable 6mo
  
  be my guest, convince the rust core team to make a spec, and make each rfc modify the spec
  
  @afdanilkin 6mo
  
  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 6mo
  
  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 6mo
  
  Which infrastructure?
  
  @feedable 6mo
  
  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 6mo
  
  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 6mo
  
  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 6mo
  
  (well, as much leverage as just a random guy submitting an rfc)
  
  @afdanilkin 6mo
  
  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 6mo
  
  those are parts of the same organization
  
  @afdanilkin 6mo
  
  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 6mo
  
  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 6mo
  
  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 6mo
  
  I do know the basics, but I don't really follow them closely anymore, since leaving rust scene
  
  @afdanilkin 6mo
  
  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 6mo
  
  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 6mo
  
  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 6mo
  
  No news, just that the spec is just not complete (or even nearly complete enough)
  
  @afdanilkin 6mo
  
  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 6mo
  
  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 6mo
  
  And I remember that there were breaking changes to at least trait resolution when I was using rust
  
  @afdanilkin 6mo
  
  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 6mo
  
  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 6mo
  
  (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 6mo
  
  GCC has bugs and what is considered confomant changes over time, including when targeting the same standard version
  
  @feedable 6mo
  
  The difference still being that you as a user know what to expect (because everything else applies to rustc too)
  
  @afdanilkin 6mo
  
  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 6mo
  
  Code still can compile but then behave differently
  
  @afdanilkin 6mo
  
  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 6mo
  
  that's the part you can't do without a spec
  
  @afdanilkin 6mo
  
  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 6mo
  
  Yeah, I'm aware, but that's still not enough
  
  _ 6mo
  
  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 6mo
  
  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 6mo
  
  do you actually know how many are there?
  
  @feedable 6mo
  
  and what are the reason they are there?
  
  @afdanilkin 6mo
  
  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 6mo
  
  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 6mo
  
  This is important
  
  @feedable 6mo
  
  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 6mo
  
  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 6mo
  
  yes, those efforts arose from understanding that a spec needs to exist, for c and js and web
  
  @feedable 6mo
  
  internet explorer came way later, when web was already standardized
  
  @afdanilkin 6mo
  
  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 6mo
  
  these are just concessions to implementations, these do arise regardless
  
  @feedable 6mo
  
  they do occur even for existing standards, the c++ standard immediately comes to mind here
  
  @afdanilkin 6mo
  
  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 6mo
  
  Less than I expected tbh
  
  @DerKnerd 6mo
  
  still too much
  
  @feedable 6mo
  
  it's not
  
  @afdanilkin 6mo
  
  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 6mo
  
  I know about both of them, and I read the c standard many times already
  
  @afdanilkin 6mo
  
  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 6mo
  
  I ported gcc to a new arch
  
  @afdanilkin 6mo
  
  That’s really cool!
  
  @feedable 6mo
  
  (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 6mo
  
  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 6mo
  
  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 6mo
  
  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 6mo
  
  or, even worse, not being able to compile spec compliant code with the same outcome on two different compilers
  
  @feedable 6mo
  
  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 6mo

that seriously kills a significant long tail of devices on which tools that require it can be compiled

@TheFloofyFloof 6mo

is that bad? Do people really need to compile on tiny hardware?
1. @hoodiepaws 6mo
  
  YES

@hoodiepaws 6mo

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 🙃

@tema3210 6mo

old weird environments gonna be supported by whom? also, why on earth anyone would get anything with less than 8GB ram nowadays?
1. @hoodiepaws 6mo
  
  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 6mo
  
  Since when latest macbook is common denominator?
  
  @tema3210 6mo
  
  And since when white american man became common denominator? 😂
  
  @sysoevyarik 6mo
  
  "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"
2. @hoodiepaws 6mo
  
  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 6mo
  
  the whole point of the unix philosophy, once upon a time. no longer.
  
  @tema3210 6mo
  
  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
  
  _ 6mo
  
  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 6mo
  
  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 6mo
  
  and that's why we don't just make assumptions, we research, gather data about devices
  
  @azizhakberdiev 6mo
  
  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
3. @RiedleroD 6mo
  
  money
  
  @tema3210 6mo
  
  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
4. @ner0xt 6mo
  
  phones and micro controllers
  
  @tema3210 6mo
  
  Not a single sould would run a fully blown compiler toolchain there - just bad fit for the task.
  
  @ner0xt 6mo
  
  welcome to the winlator/mobox community
5. @TarasPushkar24 6mo
  
  All raspberries for example, or basically any embedded devices
@afdanilkin 6mo

Is solving this by making Rust compatible with these devices possible?
@RealMrCactus 6mo

You don't need rust installed to use the binary though????
1. @TheFloofyFloof 6mo
  
  they are specifically talking about compiling git on e-waste
  
  @RealMrCactus 6mo
  
  I still don't see the problem

@hoodiepaws 6mo

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 6mo

2 questions: WHY RUST? Why not go with https://gameoftrees.org/ ?

@b7sum 6mo

haven't expected anyone to mention this here
1. @charachan 6mo
  
  likewise.
@sysoevyarik 6mo

Zoomers created new shiny VCS again?
1. @b7sum 6mo
  
  that's a project by openbsd
  
  @sysoevyarik 6mo
  
  And therefore it's not by zoomers (and especially not for zoomers)?
  
  @b7sum 6mo
  
  don't know hbu but i don't think it matters

@Johnny_bit 6mo

I mean just look at the logo...

@Johnny_bit 6mo

it's beautiful!

@dsmagikswsa 6mo

WD-40 ads detected

@hoodiepaws 6mo

holy shit i cannot believe i need to explain this.

@afdanilkin 6mo

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?
1. @hoodiepaws 6mo
  
  https://t.me/devs_chat/189433
  
  @afdanilkin 6mo
  
  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
  
  _ 6mo
  
  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 6mo
  
  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 6mo

actually you know what i’ve decided i’m better off not. sorry. ignore this old person. everyone have a nice day etc

@stilriv 6mo

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 6mo

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

@nyxiereal 6mo

LMAOOOO

@nyxiereal 6mo

Of course this loser hates rust

@Johnny_bit 6mo

Obviously oxidative degradation of materials is bad. Maintain your equipment and keep it rust free.

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

Description

Categories

Common Tags

Comments

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

Description

Categories

Common Tags

Comments

More like this

The Reviewer Wears the Full Test Suite

Removing Claude From the Commit

Self-Host GitHub? Impossible to Match That 89% Uptime