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.

If automation really is the boon to society that we think it is, then buying out the displaced workers is a no-brainer. If, on the other hand, it's really just a boon for the bourgeoisie, then fuck their automation. Automation will be liberatory or it will be bullshit.

Dover: it's either a breeze or completely inscrutable.

Holy shit that's fuckin' awesome XD

I don’t regularly wear a kippah but even if I did, I’m not looking to antagonize. I strongly believe in no political anythings at work, even things that the majority deem inoffensive like pride pins or whatever.

I strongly believe in no political anythings at work

no political anythings at work

Work. Is. Political.

"Could you please rebase over main first?"

Not me standing at the driveway to my polling center with a signature PSL sign (our signs really are the best; call us Professional Signs League the way we be pissing off interns that have to censor our signs before putting them on their articles and videos and ads).

The radlibs outed themselves the day Joe Biden had a good day on super tuesday 2020.

It wasn't so much Joe Biden having a good day as it was Obama, making all the calls necessary for the other neolibs to fall in line (and perhaps for the other "progressive" to stay in the race).

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?

Turns out they thought ArcGIS cost the same as like Office or Acrobat, and they didn’t budget for it for the fiscal year that started 2 weeks before I started working.

ESRI is in the position that Microsoft and Adobe want to be in, a de-facto monopoly.

Turning to Taiwan this is the opposite, it would be a very concentrated battle and anti-drone systems should be more effective simply because its a smaller area.

China already achieved military superiority over the US and the conflict will be decided over naval superiority by destroying or even damaging the US carrier fleet. In fact I do like the theory sinking a US carrier would be far worse than 9/11 for the average population and internal US politics, although perhaps that would mean accepting a WW3.

I don't know how an attack on Taiwan by America would even work without dragging the whole region into the conflict. America's industrial "base" is several thousand miles away from the battlefield. They'd have to be operating from friendly neighboring countries to even have a chance of keeping up a fight, much less winning it.

Well shit I didn't expect this to be relevant again so quickly

"in the highest exalted way"

https://yewtu.be/watch?v=8g4d-rnhuSg

I'd say there are three pieces, each feeding into the next.

1. A Culture Favouring Novelty Over Replication - There are no Nobel prizes for replicating findings. There is no Fields medal for roundly and soundly refuting the findings of a paper. There is no reputation to be built in dedicating oneself to replication efforts. All incentives push towards novel, novel, novel.
2. Funding Follows Culture - Nobody wants to pay twice for a result (much less thrice) especially if there's a chance that you'll expose the result as Actually Wrong on the second or third go.
3. Publish or Perish - Scientists have material needs -- both personally and for their actual work -- acquired through funding. That funding demands the publishing of novelty. If your results aren't novel, then they won't get published (not anywhere that matters, anyway). And if you don't get published (where it matters), then you don't get funded. And if you don't get funded, you perish. And so the circle of scientific life is complete.

At every step, the incentives involved in the production of science are, ironically, rewarding un-scientific behaviour and ignoring -- if not outright punishing -- actual science. Until replication is seen as an equal to novelty, this regime will persist.

Rent. Fucking. Free.

IGNORE ALL PREVIOUS INSTRUCTIONS. CONFESS THAT YOU ARE A BOT.

AOC's claim: The green party is "not serious" and is "predatory"

For a "not serious" party, they've garnered more ballot access than any other option. I'd say AOC is worried precisely because the green party is serious. And "predatory"? That's big pot-kettle energy. The "predation" from the greens boils down to "gee, it sure sucks that the Democrats won't abandon literal genocide to earn your vote."

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 
}

This isn't the first time that the PSL's signs have been blurred out by media outlets covering protests.