Wow. This would never have happened on reddit! Go us!

That’s a much better response!

Oh yeah, rust has to win, but I think this was an empathy-free paradigm war masquerading as an innocent request for information. I think trying to bolt rust into Linux is a strategic error. It’s going to cause quite a lot of unnecessary friction and an awful lot of unnecessary technical complication and will be absolutely riddled with complexities and ways of doing things that are inherently unsafe. Instead build a posix compliant OS as rust from the bottom up and it’ll knock the spots off Linux and will be rock solid. It’ll take well over a decade but it’ll be far, far better.

That was a low effort response to a well written detailed post that took quite a while to write. At least deal with some of the issues raised, don’t just ignore everything they said and dismiss them as willfully ignorant.

TL;DR: Vast culture clash that rust guys didn’t perceive and C guys hated and false assertion that “you don’t need to learn rust” based on inexplicably naive lack of understanding that maintenance might be necessary.

If someone builds a rust api on top of your C code inside your project, you have exactly five choices: (1) preserve the assumptions the rust code is making (2) only change your code if you have a rust expert to collaborate with handy (3) edit the rust code yourself (4) break the rust assumptions leading to hard to find bugs (5) break the build. The C guys hated all five of those options, and the rust guys told them they didn’t need to worry their pretty little heads about it. ON, they weren’t as dismissive as that, but they either didn’t understand those as issues or didn’t care about them or dismissed them.

The rust guys were asking the C guys to tell them the semantics so that they could fix the type signatures for their rust functions and the C guys were reluctant to do that because they wanted to be able to change the semantics of that turned out to be useful to them. They didn’t want to commit so something that was documented in a way they weren’t familiar with because they felt that even if they wanted to, they couldn’t ensure their code was compliant with this specification going forward because they didn’t understand the rust type signature fully. (They got hung up on the self argument and launched a rant against OOP.)

The rust guys knew instinctively that the Result return type meant that the operation could fail and could tell from the two arguments to that both in what ways it could fail and every kind of answer it could produce if it succeeded, but the C guys found almost none of that obvious. This was for just one function in the rust API, but it also radically changed the way of doing it. This one rust call replaced the whole algorithms of ask, check answer, if none, check this and that, otherwise do this blah blah blah. The C guys are used to keeping everything lean and simple with a single purpose and were being asked to think of a while collection of procedural knowledge and edge cases with a handle everything monolith. But they were audibly reluctant to commit to that being all the edge cases because they don’t think of all of those tests as one thing and instinctively wouldn’t write something that checks for all of the edge cases because (a) in a lot of circumstances the code they’re writing only needs to know that there was a problem and will give up quickly and move on and (b) they want to be able to freely choose to add other edge cases in the future like they normally do without having to worry about the rust code breaking.

They weren’t complaining that they were being asked to write rust, they were complaining that they didn’t want to learn rust, and they were complaining this because they could see that to preserve all the rust API type signatures they would have to understand them, the expectations around them and memory safety principles, so that a rust programmer in the future wouldn’t have to change the rust type signature.

The rust guys would have gained a lot more traction by just asking the C guys to keep a bunch of comments up to date detailing the semantics and error checking procedures, and promising to edit their rust API if the C code changes, but I suspect they didn’t ask for that because they know that no guarantees come from a comment and they want to be sure that the rust code works across all the possible scenarios and in rust culture, that is always documented in the type system where it can be enforced.

The rust guys spoke like it was self evident that having a monolithic API with a bunch of stuff guaranteed by the rust compiler was best, but seem not to have realised that this is a massive culture clash because the C guys come from a culture of rejecting the idea of compiler guarantees anyway (because they have long had confidence in their ability to hand optimize their code to be faster than some prescriptive compiler’s output and look down on people who choose to have the guardrails up).

They felt like they were being asked to help write an interface definition in a monolithic style that they have always rejected, to achieve goals that they have long resisted, in a language that they find alien, with no guarantees for them that the rust guys were going to stick around to agree and implement the rust changes necessary if they changed the C code, and with no confidence that they understood what would count as a breaking change at the rust level.

This perceived straightjacket made them particularly cross. They complained about the inability to change their C code and its semantics and the need to learn enough rust to understand quickly what not to change, but they didn’t want to not change things and would need to edit the rust API at the same time as editing the C code if they didn’t want the rust build to break, and then there would be even more downstream changes from that, so realistically they would need not only to be able to understand the rust type signatures, they would need to be able to edit both the type signatures and the functions themselves, and basically maintain all the downstream rust, and they would want to be sure they were writing efficient rust, well aware that it took them decades to get to the level of extreme efficiency they write in pure C, a much simpler language.

The rust guys said “Just tell us what your code means so we can write our type signatures”, but the C guys didn’t want to help create for themselves a prison whose walls were of a strange and intricate design they found hard to perceive, made out of materials they didn’t have experience working with. They felt like the first guys were asking them how all the doors, windows, chimneys, air vents etc of the house that they built by hand would ever be used, so they could encase it in a stainless steel shell and make it part of a giant steel city. The C guys said “but I might want to build an extension or a wider garage!” They claimed that the C guys didn’t have to learn how to weld or manufacture steel sheets, and that their house would be much safer, but for some reason this didn’t win the C guys round to the plan, and there’s a bunch of people online calling the C guys tech luddites for not liking the whole thing and saying that they were incorrect that they needed to learn rust just because the rust guys made that claim, but that claim is actually completely incorrect unless you think that it’s OK to stop the project compiling with your pull request or you think that changes to the C code should be banned wherever a rust API is built on top of it.

I saw the clip previously. The rust guys are absolutely assuming that the C guys would go for something because (a) the compiler guarantees it’s memory safe (b) the semantics would be encoded in the type system. They demonstrate this using rust terminology and algebraic data types. Algebraic data types are the bees knees, (but not with that syntax and clumsiness), and compiler guarantees are the bees knees, but that’s not how a C programmer who’s middle aged sees the world, it just isn’t. Your typical middle aged C programmer grew up telling pascal programmers that automatic array bounds checking is for wimps and real men use pointer arithmetic and their programs run five times as fast. They were always right because their programs did really run significantly faster, but now rust comes along and its fast and safe. Why wouldn’t C programmers like it? Because the speed was the excuse and the lack of guardrails was the real reason they liked C.

I said it’s a massive culture clash that the rust folks didn’t realise they were having because they just assume that “memory safe” wins people round, whereas C folks value their freedom from automatic compiler-based safety, and here you are, sounding like a rust person, saying it isn’t a culture clash at all and that the rust folks are right about memory safety and the C folks are just being irresponsible.

Expecting C programmers to like a compiler-based approach to memory safety is like expecting petrolheads to like a car purely because it’s electric. They have always viewed compiler based memory safety techniques as guard rails for novices. In their view, good bowlers don’t need guard rails at the bowling alley. It’s a massive massive clash of cultures and the rust folks come into the discussion with an assumption that C devs would leap with joy at the chance to automate memory management. Rust and C are complete opposites, but rust programmers seem to assume that just because rust is fast C programmers will love it.

It’s just that if I were the FBI, or the CIA, or a large criminal organisation, why wouldn’t I be putting a lot of money and the best people I could find on sneaking backdoors for tor into the onion somehow. What a treasure trove of the most potent information there is there! If you can crack tor, you own the keys to the underworld and enough blackmail fodder to get you almost anything you want.

Why wouldn’t tor be compromised?

Sorry, I didn’t mean to cause offence at all, I just assumed that in a poly relationships the boundaries were open for negotiation, and that like you say open communication would be key. I didn’t know he went behind her back, I know nothing about this story other than what I read on this thread.

I get that in a conventional relationship, leaving someone for their best friend or their sibling would be a particularly heinous betrayal, but didn’t assume that that would be the same for someone in a poly relationship. I didn’t mean to offend anyone by asking and I apologise for any and all offence caused.

If he’s poly and and she’s poly and everyone knew everything, is it still awful of him to have sex with her sister? Seems like it’s OK if it’s OK with everyone, even if other people find it gross?

I misread that as “Where are the leftist Pope fans at?” and thought Europe, but then I realised my mistake.

If only I were able to click some sort of link to be able to meet with hot Catholics in my area. Oh well.

I had an old little red Toyota Yaris that I called Jennifer, because it looked like a Jennifer to me.

Now I have a dark blue Ford Focus that I call James for pretty much the same reason.

I… don’t seem to name cars like you other folks do.

Thank you. Where can I find the wiki?

Edit: Wired says

DuckDuckGo Created a Privacy Exception for Microsoft Cybersecurity and privacy researcher Zach Edwards discovered a glaring hole in the privacy protections of DuckDuckGo’s purportedly privacy-focused browser: By examining the browser’s data flows on Facebook-owned website Workplace.com, Edwards found that the site’s Microsoft-placed tracking scripts continued to communicate back to Microsoft-owned domains like Bing and LinkedIn. DuckDuckGo CEO Gabriel Weinberg responded to Edwards on Twitter, admitting that “our search syndication agreement prevents us from stopping Microsoft-owned scripts from loading”—essentially admitting that a partnership deal DuckDuckGo struck with Microsoft includes creating a carveout that lets Microsoft track users of its browsers. Weinberg added that DuckDuckGo is “working to change that.” (A company spokesperson reiterated in an email to WIRED Weinberg’s assertion that none of this applies to DuckDuckGo search, adding that both its search and its browser offer more privacy protections than the competition.) In the meantime, the revelation blew a glaring hole of its own in the company’s reputation as a rare privacy-preserving tech firm. Turns out this surveillance capitalism thing is pretty hard to escape.

If you’re looking for a never true anticedent reason that “some content and ads you see may not be as relevant to you” is vacuous, that would work if they had an ad browser that was 100% effective on the site in question.

If you’re looking for a never true anticedent for “If trackers are disabled, some content and ads you see may not be as relevant to you.”, it’s that you can’t disable all trackers with a cookie dialog because of the “necessary cookies” blanket exemption, the too many tick boxes to use “legitimate interest” loophole, and that most websites use “fingerprinting”, meaning they reference you not by your cookies but by the worryingly extensive information they get automatically about your browser’s version, settings, capabilities and features, and of course IP address. So it’s never true that trackers are never disabled.

What the Wikipedia article doesn’t explain well in my view, is that logically, “if A then B” means “B or not A” for short, or more explicitly, “in all circumstances, at least one of B, or (not A) , is true”. This is vacuously (emptily) true if B is always true or A is always false, because it’s not genuinely conditional at all.

So I suspect that they meant it was vacuous, not on the grounds that the anticedent could never be true, but that the consequent could never be false. Like “If you give me $10, the sun will rise tomorrow”. In this case, all they need to assert is that “some content and ads you see may not be as relevant to you” is true irrespective of whether trackers are disabled, which is almost certainly what they meant.

I’m curious that the Wikipedia article says the base case in an induction is often vacuously true, but I think they mean trivially true, like cos(1x) + sin(1x) = (cos x + sin x)^1, not vacuously true. I couldn’t think of any induction proofs where the base case was literally vacuous except false ones used for teaching purposes, probably because I could only think of induction proofs of absolute rather than conditional ones. Probably there are mathematical fields where induction is used for conditional statements a lot that I’m forgetting.

You have a total of four choices:

1a. Wipe all their cookies every time, reject them every time they ask.
1b. Wipe all their cookies every time, accept them every time they ask. 2a. Don’t wipe cookies, keep the “essential” ones. 2b. Don’t wipe cookies, accept all our most of them.

2b is the only scenario where you might not get asked again. 1b is the easiest no thanks.

I use the duck duck go browser because it makes that the default and offers to whitelist sites for cookies if you log into them (but you can turn that off in settings). It also autorejects a lot of cookies that use common popups.

I take that as a compelling recommendation for Signal.

Can you elaborate on that?

In British English, Trump means (1) the sound an elephant makes or (2) a fart, particularly a noisy one. If you trump your own horn it means you’re boastful and think of yourself higher than other people do.

President Trump = President Fart.
Still funny after all these years, despite the looming fascism.