Yeah, the community run TCRF wiki is banning VPNs just so they can mine your data along with the luxurious $400/mo they're getting from Patreon. And not because they're constantly being besieged by rampant bots that they have to resort to such drastic measures.
This is fascinating to me, because you just said you can't see it, but also that there are "trackers from multiple big corporations". Can you tell me what those are?
I ask primarily because we explicitly don't use any trackers, to a degree I actually pride myself on running a website that doesn't contact anything else:
https://mini.xkeeper.net/private/C58L77azpY.png
The sole exceptions are YouTube embeds, afaik. I even switched out the MediaWiki and CC badges to be local.
On the “ Sorry, you are not allowed to access tcrf.net right now” page I get tracked by Google, YouTube and DoubleClick according to the report by Safari.
I also have 924 kilobyte of data stored on my device after visiting tcrf.net without any consent.
uBlock Origin shows nothing out of the ordinary but Youtube, Google and Doubleclick, so Google, Google and Google, and I assume all of those are due to the embed.
If you mean the block page, yes, that's just the YouTube embed. You'll see the same results on any wiki page that has a YouTube embed for the same reason; it's not tracking or anything I have control over (other than outright not having YouTube embeds). But I think if anyone has concerns over that, they're better addressed at the local-user level by disabling all unauthorized iframes.
There are lightweight YouTube embeds like https://github.com/paulirish/lite-youtube-embed.
It’s lauded for faster page loads, but it likely has good privacy implications too since it basically just loads a thumbnail unless you click on it.
Also, to what extent you designed this vs the LLM copying it?
My concern is all these vibe coded projects with huge readmes and fake GitHub stars are essentially just copying the work of others, and don’t really do anything new.
Where do you see 600k commits? Are you talking about 600k lines of code? If so, the project includes libraries in the `lib` folder, notably a large screen library called `tft_espi` which must be 500k lines on its own (which has since been removed, that's why you see -500k lines)
I know the codebase inside and out, feel free to ask
The implementation is entirely new and was built specifically for this project, it is not copied from another project. LLMs were used as development tools, but the architecture, feature selection, integration, testing, and overall direction were designed and validated by contributors and me.
If the repo is what I think it is, the underlying bug is over a decade old [0]. From what I understand the devs have known how to solve it for pretty much this entire time, but their desired solution is blocked on some rather large refactorings elsewhere in the compiler.
> are there flaws in Rust that aren’t edge cases that would make it not memory safe?
cve-rs is probably the most well-known one, but it's definitely not the only one [1]. That being said, I think there's a not-unreasonable argument to be made that cve-rs counts as an edge case since (as far as I know) there's no publicly-known examples of code that has "organically" run into this.
On a more practical note, I think if you're worried about memory safety in Rust code type system holes are vanishingly unlikely to be the cause compared to more "normal" things like mistakes in-around `unsafe` blocks.
I don’t know what your point is. Unsafe blocks in the stdlib isn’t a gotcha. It’s the whole point of unsafe: you provide a validated and ideally proveably correct implementation once, with a safe wrapper. It’s how everything is implemented under the hood.
It’s like double entry accounting when you only have one pen and one writing hand. The system is broken if you ever write down only half of a transaction in one ledger: you always need to record both the flow in and flow out on both ledgers. Writing either one of them is an unsafe operation. But you can only write one thing at a time. So write them in pairs in an unsafe {} block, and reuse that block safely.
So you are fine in calling a language "safe", when it has unsafe blocks, which the compiler skips to check? You have to that manually, and then you are back in C++ land. That's hilarious. You can call it somewhat safe, or mostly safe, but never safe.
Alternatively, you can have a fully safe language, and then to get certain things done you add fundamentally unsafe FFI[1]. Or you use IPC to a process written in an unsafe language. Again, you're "back in C++ land".
It seems like your complaint is that Rust is referred to as a safe language. Which is fine; it's more correct to use the phrase "in safe Rust" rather than assuming that "in Rust" fully implies "safe". That is true, but that's a crack in a sidewalk compared to the chasm of difference between Rust and C++. Why obsess over that crack?
Should we all refer to "Python without FFI or any extensions written in C or another unsafe language" instead of "Python", to avoid asserting that Python-as-it-is-used is a safe language?
[1] Assuming it's FFI to an unsafe language, and that's the main purpose of FFI.
The perfectly safe platonic ideal you are implying cannot exist. Rust is a safe language because it bounds the unsafely to the minimal, clearly demarcated area where it can be reviewed and proven (outside the bounds of the type system) to hold.
Real machines and reality aren't built out of safe primitives. Safe constructs have to be built out of unsafe components. That's just how computers work.
Sure, that's why safe languages forbid users to use unsafe things.
"C programmers think memory management is too important to be left to the computer. Lisp programmers think memory management is too important to be left to the user."
Ellis and Stroustrup, The Annotated C++ Reference Manual.
You need a systems programming language to write safe systems. That's what Rust is. Maybe there's room for a higher-level 100% safe language. Rust would be a good language to write it in.
In the mean time, in the messy world of writing software today, one does frequently enough come across the need for new safety primitives. Things that are provably correct but which the type system of your language does not support. In these instances, unsafe lets you lower down into systems code to build and safely wrap these new components.
Yes, Rust is a good systems programming language. Just not safe. Safer than most others, yes. Good enough, yes.
But there exist safe systems programming languages. Safe systems were done in these languages. Just nobody cared, so they died or have no market share.
Do I have to do osdev language research for you now? I'm certainly missing some, but out of my head: Mesa/Cedar, Concurrent Pascal, Smalltalk, Lisp, ADA, C#/M# for Midori/Singularity, Oberon, ...
All of those have unsafe-like escape hatches, with the notable and singular exception of Concurrent Pascal. In each of the others you can access their own version of `unsafe` as an escape hatch
Mesa/Cedar: LOOPHOLE inside an UNSAFE module
Smalltalk 80: You can access the built-in VM instructions directly using the <primitive: N> syntax. E.g. basicAt:put: at <primitive: 61> avoids bounds checks and type checks.
Common Lisp: (safety 0)
Ada: Unchecked_Conversion, Unchecked_Deallocation
C#/M#: unsafe class MyClass<T> where T : unmanaged
Oberon: the SYSTEM module
Rust isn't any different, and unsafe exists in Rust for the same reason it exists in all these other languages. You use it to create new constructs the language authors didn't foresee. Concurrent Pascal is the singular exception: You can't do anything the language doesn't provide out of the box. Need something Brinch Hansen didn't think of? Sucks to be you.
If you want the rusty version of Concurrent Pascal though, you can have that. Put #![forbid(unsafe_code)] in your crate's lib.rs, or your Cargo.toml. Done.
While Ada does have `Unchecked_Deallocation` and `Unchecked_Conversion`, Ada out-of-the-box provides safety roughly on-par with the high-integrity C++ style-guide. For provable safety, the SPARK subset/provers are used.
There's a lot you can do in Ada without resorting to them, and even with using them it can be perfectly fine, such as (eg) "view conversion" of a register or memory-mapped location -- remember that a lot of APIs (and ABIs) have been kneecapped by catering to C's inabilities, so even if the idea is directly expressible in some higher level language it will be exposed at the lower level.
And Rust out of the box is safe by default, and you never have to resort to using unsafe {} blocks in normal usage.
I'm not trying to fight some religious war here. You want to use Ada? Great! But don't pretend that the existence of the unsafe keyword somehow makes Rust unacceptably impure. The same escape hatches exist in every other "safe" language outside of the one toy example whose entire niche purpose was to avoid unsafe, and which no one uses now because the language is ossified and non-extensible.
reply