Mozilla agrees that we need to improve search competition, but the DOJ’s proposed remedies unnecessarily risk harming browser competition instead.

The only one hurting browser competition is Mozilla. They want to keep sucking at the teat of BigTech. They don’t want to be a non-profit with a focused mission, constrained by recurring and one-off revenues. They want to be an adtech company, bUt wiTH pRivAcY. The judge should absolutely rip the band-aid off. If Mozilla sinks, it sinks.

Just gonna leave this here…

https://blog.brixit.nl/developers-are-lazy-thus-flatpak/

You know, the thing that always seemed really scary about the OG Nazis is that they were competent, intelligent, put-together people that were just fucking evil. Then you look at the US Nazis and the fucking bozo density is off the charts, but they seem to be succeeding anyway.

Not every fascist and Nazi needed to be competent, intelligent, and put-together. Just enough of them. I suppose we’ll find out in real-time if they have amassed sufficient numbers this go 'round.

NoSQL is web-scale.

Hellwig could have been more tactful, but like it or not, arguments against a cross-language codebase have merit. Framing it as a ‘clear confession of sabotage of the r4l project’, attempting to weaponize the CoC, and trying to drum up an army via social media was all out of line.

When a maintainer calls somebody’s efforts “cancer” – “spreading this cancer to core subsystems” – and that they’ll do everything they can to halt those efforts – “I will do everything I can do to stop this” – that’s as clear an indication of sabotage as you will ever get.

Martin seems to understand that adding a second language to the kernel is not only a technical concern, but a political one as well. Everyone else wants to pretend politics isn’t at play and that their objections are “purely technical.” They aren’t. I definitely understand Martin’s frustration here.

for it to be plain sailing adding it to the kernel some of the worlds’ foremost domain experts on operating systems would have to re-learn basically everything.

This is the core problem. It’s a social problem, not a technical one.

We know that not everyone in our community will embrace our entrance into this market. But taking on controversial topics because we believe they make the internet better for all of us is a key feature of Mozilla’s history. And that willingness to take on the hard things, even when not universally accepted, is exactly what the internet needs today.

But you’re not doing the hard things. You’re doing the easy thing. Capitulation to surveillance capitalism is the easy thing.

“Could you please rebase over main first?”

Perhaps I should rephrase. They attack Mozilla (and users of Firefox) infinitely more than Google (and users of various Google products). I heard it said after Mozilla introduced their opt-out privacy-respecting ad tracking that users should “move to a more privacy-friendly browser like Google Chrome”.

One of those entities claims to be on the side of users. When it constantly throws those same users under the bus anyway, it isn’t surprising that it gets more hate than the entity that removed “don’t be evil” from its motto.

Tell them you’re a liberal? You’re practically a Nazi collaborator!

It’s not our fault that fascists bleed when liberals get scratched.

Similarly, I find a fair number of Rust crates (that I want to use) have virtually no doc or inline examples, and use weird metaprogramming that I can’t wrap my head around.

Is it really a true rust crate if it doesn’t contain at least one inscrutable macro?

I’ll try :) Looks like I still have my code from when I was grinding through The Book, and there’s a couple spots that might be illuminating from a pedagogical standpoint. That being said, I’m sure my thought process, and “what was active code and what was commented out and when,” will probably be hard to follow.

My first confusion was in deref coercion auto dereferencing (edit: see? it’s still probably not 100% in my head :P), and my confusion pretty much matched this StackOverflow entry:

https://stackoverflow.com/questions/28519997/what-are-rusts-exact-auto-dereferencing-rules

It took me until Chapter 15 of The Book (on Boxes) to really get a feel for what was happening. My work and comments for Chapter 15:

use crate::List::{Cons, Nil};
use std::ops::Deref;

enum List {
    Cons(i32, Box<List>),
    Nil,
}

struct MyBox<T>(T);

impl<T> Deref for MyBox<T> {
    type Target = T;
    fn deref(&self) -> &Self::Target {
        &self.0
    }
}

impl<T> MyBox<T> {
    fn new(x: T) -> MyBox<T> {
        MyBox(x)
    }
}

#[derive(Debug)]
struct CustomSmartPointer {
    data: String,
}

impl Drop for CustomSmartPointer {
    fn drop(&mut self) {
        println!("Dropping CustomSmartPointer with data `{}`!", self.data);
    }
}

fn main() {
    let b = Box::new(5);
    println!("b = {}", b);

    let _list = Cons(1, Box::new(Cons(2, Box::new(Cons(3,Box::new(Nil))))));

    let x = 5;
    let y = MyBox::new(x);

    assert_eq!(5,x);
    assert_eq!(5, *y);

    let m = MyBox::new(String::from("Rust"));
    hello(&m);
    hello(m.deref());
    hello(m.deref().deref());
    hello(&(*m)[..]);
    hello(&(m.deref())[..]);
    hello(&(*(m.deref()))[..]);
    hello(&(*(m.deref())));
    hello((*(m.deref())).deref());

    // so many equivalent ways. I think I'm understanding what happens
    // at various stages though, and why deref coercion was added to
    // the language. Would cut down on arguing over which of these myriad
    // cases is "idomatic." Instead, let the compiler figure out if there's
    // a path to the desired end state (&str).

    // drop stuff below ...
    let _c = CustomSmartPointer {
        data: String::from("my stuff"),
    };
    let _d = CustomSmartPointer {
        data: String::from("other stuff"),
    };

    println!("CustomSmartPointers created.");
    drop(_c);
    println!("CustomSmartPointer dropped before the end of main.");

    // this should fail.
    //println!("{:?}", _c);
    // yep, it does.

}

fn hello(name: &str) {
    println!("Hello, {name}!");
}

Another thing that ended up biting me in the ass was Non-Lexical Lifetimes (NLLs). My code from Chapter 8 (on HashMaps):

use std::collections::HashMap;

fn print_type_of<T>(_: &T) {
    println!("{}", std::any::type_name::<T>())
}

fn main() {
    let mut scores = HashMap::new();
    scores.insert(String::from("Red"), 10);
    scores.insert(String::from("Blue"), 20);

    let score1 = scores.get(&String::from("Blue")).unwrap_or(&0);
    println!("score for blue is {score1}");
    print_type_of(&score1); //&i32
    let score2 = scores.get(&String::from("Blue")).copied().unwrap_or(0);
    println!("score for blue is {score2}");
    print_type_of(&score2); //i32

    // hmmm... I'm thinking score1 is a "borrow" of memory "owned" by the
    // hashmap. What if we modify the blue teams score now? My gut tells
    // me the compiler would complain, since `score1` is no longer what
    // we thought it was. But would touching the score of Red in the hash
    // map still be valid? Let's find out.

    // Yep! The below two lines barf!
    //scores.insert(String::from("Blue"),15);
    //println!("score for blue is {score1}");

    // But can we fiddle with red independently?
    // Nope. Not valid. So... the ownership must be on the HashMap as a whole,
    // not pieces of its memory. I wonder if there's a way to make ownership
    // more piecemeal than that.
    //scores.insert(String::from("Red"),25);
    //println!("score for blue is {score1}");

    // And what if we pass in references/borrows for the value?
    let mut refscores = HashMap::new();
    let mut red_score:u32 = 11;
    let mut blue_score:u32 = 21;
    let default:u32 = 0;
    refscores.insert(String::from("red"),&red_score);
    refscores.insert(String::from("blue"),&blue_score);

    let refscore1 = refscores.get(&String::from("red")).copied().unwrap_or(&default);
    println!("refscore1 is {refscore1}");

    // and then update the underlying value?
    // Yep. This barfs, as expected. Can't mutate red_score because it's
    // borrowed inside the HashMap.
    //red_score = 12;
    //println!("refscore1 is {refscore1}");

    // what if we have mutable refs/borrows though? is that allowed?
    let mut mutrefscores = HashMap::new();
    let mut yellow_score:u32 = 12;
    let mut green_score:u32 = 22;
    let mut default2:u32 = 0;
    mutrefscores.insert(String::from("yellow"),&mut yellow_score);
    mutrefscores.insert(String::from("green"),&mut green_score);
    //println!("{:?}", mutrefscores);

    let mutrefscore1 = mutrefscores.get(&String::from("yellow")).unwrap();//.unwrap_or(&&default2);
    //println!("{:?}",mutrefscore1);
    
    println!("mutrefscore1 is {mutrefscore1}");

    // so it's allowed. But do we have the same "can't mutate in two places"
    // rule? I think so. Let's find out.

    // yep. same failure as before. makes sense.
    //yellow_score = 13;
    //println!("mutrefscore1 is {mutrefscore1}");

    // updating entries...
    let mut update = HashMap::new();
    update.insert(String::from("blue"),10);
    //let redscore = update.entry(String::from("red")).or_insert(50);
    update.entry(String::from("red")).or_insert(50);
    //let bluescore = update.entry(String::from("blue")).or_insert(12);
    update.entry(String::from("blue")).or_insert(12);


    //println!("redscore is {redscore}");
    //println!("bluescore is {bluescore}");
    println!("{:?}",update);

    // hmmm.... so we can iterate one by one and do the redscore/bluescore
    // dance, but not in the same scope I guess.
    let mut updatesingle = HashMap::new();
    updatesingle.insert(String::from("blue"),10);
    for i in "blue red".split_whitespace() {
        let score = updatesingle.entry(String::from(i)).or_insert(99);
        println!("score is {score}");
    }

    // update based on contents
    let lolwut = "hello world wonderful world";
    let mut lolmap = HashMap::new();
    for word in lolwut.split_whitespace() {
        let entry = lolmap.entry(word).or_insert(0);
        *entry += 1;
    }

    println!("{:?}",lolmap);

    // it seems like you can only borrow the HashMap as a whole.
    // let's try updating entries outside the context of a forloop.

    let mut test = HashMap::new();
    test.insert(String::from("hello"),0);
    test.insert(String::from("world"),0);
    let hello = test.entry(String::from("hello")).or_insert(0);
    *hello += 1;
    let world = test.entry(String::from("world")).or_insert(0);
    *world += 1;

    println!("{:?}",test);

    // huh? Why does this work? I'm borrowing two sections of the hashmap like before in the update
    // section.
    
    // what if i print the actual hello or world...
    // nope. barfs still.
    //println!("hello is {hello}");

    // I *think* what is happening here has to do with lifetimes. E.g.,
    // when I introduce the println macro for hello variable, the lifetime
    // gets extended and "crosses over" the second borrow, violating the
    // borrow checker rules. But, if there is no println macro for the hello
    // variable, then the lifetime for each test.entry is just the line it
    // happens on.
    //
    // Yeah. Looks like it has to do with Non-Lexical Lifetimes (NLLs), a
    // feature since 2018. I've been thinking of lifetimes as lexical this
    // whole time. And before 2018, that was correct. Now though, the compiler
    // is "smarter."
    //
    // https://stackoverflow.com/questions/52909623/rust-multiple-mutable-borrowing
    //
    //   https://stackoverflow.com/questions/50251487/what-are-non-lexical-lifetimes
    //let 
}

What kind of type signature would prove the first block of any directory in an ext4 filesystem image isn’t a hole?

I don’t know if the type system proves it’s not a hole, but the type system certainly seems to force consumers to contend with the possibility by surfacing the outcomes at the type system level. That’s what the Either is doing in the example’s return type, is it not?

fn get_or_create_inode(
    &self,
    ino: Ino
) -> Result<Either<ARef<Inode<T>>, inode::New<T>>>

You get used to the syntax and borrow checker in a day or two.

As someone who spent a couple months learning rust, this was half true for me. The syntax? Yeah. No problem. The borrow-checker (and Rust’s concept of ownership and lifetimes in general)? Absolutely not. That was entirely new territory for me.

Isn’t Linux still Linux even though probably a lot of the original code is gone?

The Kernel of Theseus.

Yeah, Signal is more than encrypted messaging it’s a metadata harvesting platform. It collects phone numbers of its users, which can be used to identify people making it a data collection tool that resides on a central server in the US. By cross-referencing these identities with data from other companies like Google or Meta, the government can create a comprehensive picture of people’s connections and affiliations.

This allows identifying people of interest and building detailed graphs of their relationships. Signal may seem like an innocuous messaging app on the surface, but it cold easily play a crucial role in government data collection efforts.

Strictly speaking, the social graph harvesting portion would be under the Google umbrella, as, IIRC, Signal relies on Google Play Services for delivering messages to recipients. Signal’s sealed sender and “allow sealed sender from anyone” options go part way to addressing this problem, but last I checked, neither of those options are enabled by default.

However, sealed sender on its own isn’t helpful for preventing build-up of social graphs. Under normal circumstances, Google Play Services knows the IP address of the sending and receiving device, regardless of whether or not sealed sender is enabled. And we already know, thanks to Snowden, that the feds have been vacuuming up all of Google’s data for over a decade now. Under normal circumstances, Google/the feds/the NSA can make very educated guesses about who is talking to who.

In order to avoid a build-up of social graphs, you need both the sealed sender feature and an anonymity overlay network, to make the IP addresses gathered not be tied back to the endpoints. You can do this. There is the Orbot app for Android which you can install, and have it route Signal app traffic through the Tor network, meaning that Google Play Services will see a sealed sender envelope emanating from the Tor Network, and have no (easy) way of linking that envelope back to a particular sender device.

Under this regime, the most Google/the feds/the NSA can accumulate is that different users receive messages from unknown people at particular times (and if you’re willing to sacrifice low latency with something like the I2P network, then even the particular times go away). If Signal were to go all in on having client-side spam protection, then that too would add a layer of plausible deniability to recipients; any particular message received could well be spam. Hell, spam practically becomes a feature of the network at that point, muddying the social graph waters further.

That Signal has

1. Not made sealed sender and “allow sealed sender from anyone” the default, and
2. Not incorporated anonymizing overlay routing via tor (or some other network like I2P) into the app itself, and
3. Is still in operation in the heart of the U.S. empire

tells me that the Feds/the NSA are content with the current status quo. They get to know the vast, vast majority of who is talking (privately) to who, in practically real time, along with copious details on the endpoint devices, should they deem tailored access operations/TAO a necessary addition to their surveillance to fully compromise the endpoints and get message info as well as metadata. And the handful of people that jump through the hoops of

1. Enabling sealed sender
2. Enabling “allow sealed sender from anyone”
3. Routing app traffic over an anonymizing overlay network (and ideally having their recipients also do so)

can instead be marked for more intensive human intelligence operations as needed.

Finally, the requirement of a phone number makes the Fed’s/the NSA’s job much easier for getting an initial “fix” on recipients that they catch via attempts to surveil the anonymizing overlay network (as we know the NSA tries to). If they get even one envelope, they know which phone company to go knocking on to get info on where that number is, who it belongs to, etc.

This too can be subverted by getting burner SIMs, but that is a difficult task. A task that could be obviated if Signal instead allowed anonymous sign-ups to its network.

That Signal has pushed back hard on every attempt to remove the need for a phone number tells me that they have already been told by the Feds/the NSA that that is a red line, and that, should they drop that requirement, Signal’s days of being a cushy non-profit for petite bourgeois San Francisco cypherpunks would quickly come to an end.

Meanwhile, BOINC is right there, with far more useful work for your idle GPU to do.

The problem is chatgpt will say you the wrong answer confidently unlike humans

We must be hanging around different humans.

We lost the .ml domains. Defederation happened.

Looks to me like lemmy.world still has lemmy.ml and lemmygrad.ml linked. I can see this post on All at least.

Then there is the tankie Left, which also started with good intentions but seem to have confuse the recipe-book of slogans and the Party über alles discipline invented in the late 19th century and early 20th century by middle class intellectuals to inspired the near-illiterate masses of the time to create an utopian leftwing world (which didn’t work) with the actual thinking Principles and Intentions from which the rules were made.

The “tankies” are absolutely not utopian. There was a great big schism about this very question more than a century ago, with Marxists roundly rejecting the utopianism of the libertarian socialists (Anarchists). Socialism: Utopian and Scientific by Engels is a good starting point.