Readit Newslisteria commented on CLI tool to check the Git status of multiple projects github.com/uralys/check-p... · Posted by u/chrisdugne
listeria commented on Rouille – Rust Programming, in French github.com/bnjbvr/rouille... · Posted by u/mihau
"Rustic" is actually a very common term in the Rust community, though it's an obvious joke drawing on 'Pythonic'. But there's nothing inherently wrong with "Rústico" as a name for a programming language.
That's all well and good, except the README clearly states:
> rústico (Spanish for Rust)
which is plain wrong.
listeria commented on Rouille – Rust Programming, in French github.com/bnjbvr/rouille... · Posted by u/mihau
The Russian version linked there is, uh, underwhelming. That whole gopnik vibe is entirely unwarranted. I understand a bit of Spanish and that one is much better in comparison.
I was immediately put off by the Spanish version when I saw it was called "rústico", which does not translate to rust at all, it means rustic. The Spanish word for rust would be "óxido".
That seemed to an EU thing
But I note the treaties.un.org link is signatories as of late 2024.
Why are they not publishing the current signatories? This is absolutely not something that should be murky.
you can see at the top of the page it says:
STATUS AS AT : 30-10-2025 09:16:00 EDT
full list of signatories: https://treaties.un.org/Pages/ViewDetails.aspx?src=TREATY&mt...
Why the b > 2 condition? In the b=2 case, all three formulas also work perfectly, providing a ratio of 1. And this is interesting case where the error term is integer and the only case where that error term (1) is dominant (b-2=0), while the b-2 part dominates for larger bases.
in the b=2 case, you get:
1 / 1 = 1 = b - 1
1 % 1 = 0 = b - 2
21 (base 3) = 7
12 (base 3) = 5
7 / 5 = 1 = b - 2
7 % 5 = 2 = b - 1Part of the problem is “naming/marketing.” Bat compares ITSELF to cat, not to more/less. IMO, this confuses the issue.
Maybe it should be called "lest"? As in a less/most replacement written in rust. Although it does divert from the theme of more/less/most.
Amazing, and you could see how this could be translated into perhaps a couple of thousand lines of assembly code to boostrap Scheme almost from the bare metal, similar to the early IBM 709 LISP.
A thought: I wonder if an LLM would be up to the job of writing the assembly code from this?
> I wonder if an LLM would be up to the job of writing the assembly code from this?
I could see a compiler doing that.
Not all sites are safe, either by design or by people running them. Having a common secret+service name as password AND having at least one of those sites leaking your plaintext password could mean that your derivation may go public and all your other passwords and services fall because of that.
presumably the derivation would involve a cryptographically secure, non-reversible function so as to not compromise the secret should one of them be leaked.
listeria commented on The future of 32-bit support in the kernel lwn.net/SubscriberLink/10... · Posted by u/binarycrusader
That is not specific to 32-bit system architectures. The 2038 problem is specific to timestamps that are represented as milliseconds since the Unix epoch and are stored in a 32-bit integer. It's quite possible (and common) to deal with 64-bit integers on a 32-bit system architecture.
I am also surprised how little attention the 2038 problem gets. However, I also wonder how big a problem it is. We've known about it for years and all the software I've touched is not susceptible to it.
It's actually seconds since epoch, not milliseconds. Here's a small program to verify it:
date -u --date='2038-01-19T03:14:08' +%s | perl -ne 'printf "%#x\n", $_'
[1]: https://perldoc.perl.org/Time::Piece#Use-of-epoch-seconds