"in the highest exalted way"

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

Once you’ve eliminated the cause for NATO, then dissolving NATO will make sense.

The cause for NATO was eliminated. NATO didn't dissolve. It grew. Spoiler alert: there are no good guys in a war between imperialists.

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.

How are you proposing to run society, get food, healthcare, education, have roads, clean water, internet connectivity, power, law, and all the other things that make it possible for you to express yourself here today?

The party in question (PSL) actually has taken a stab at what their vision of the first ten years of a socialist United States would look like:

https://1804books.com/products/socialist-reconstruction-a-better-future

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.

If that were the case Molly FOSS wouldn’t exist

I'm not speaking of hard dependence as in "the app can't work without it." I'm speaking to the default behavior of the Signal application:

1. It connects to Google
2. It does not make efforts to anonymize traffic
3. It does makes efforts to prevent anonymous sign-ups

Molly FOSS choosing different defaults doesn't change the fact that the "Signal" client app, which accounts for the vast majority of clients within the network, is dependent on Google.

And in either case -- using Google's Firebase system, or using Signal's websocket system -- the metadata under discussion is still not protected; the NSA doesn't care if they're wired into Google's data centers or Signal's. They'll be snooping the connections either way. And in either case, the requirement of a phone number is still present.

Perhaps I should restate my claim:

Signal per se is not the mass surveillance tool. Its dependence on Google design choices of (1) not forcing an anonymization overlay, and (2) forcing the use of a phone number, is the mass surveillance tool.

I think if there was something else major in meat that we were missing this study would have shown it.

That's fair enough. Not all nutrient deficiencies have acute presentations, and the seven indicators of illness may not account for all the ways nutrient deficiencies could present, but if the crowd shrieking about animal cruelty was right in its hyperbolic hypothesis, then it would be likely for at least one of those seven indicators to get tripped.

READ THE STUDY!

No need to shout. I did.

So you’re saying that vegan cats had roughly the same health as non vegan cats

No. That is not what the study is saying. The study is saying that "we took a look, and couldn't tell if there was a difference or not." Which is understandable, given the methodology. Internet-based questionnaires/surveys are easy to conduct, but tend to have big error bars. It's a common trade-off made when first beginning to investigate a hypothesis.

It's your typical "absence of evidence" versus "evidence of absence" conundrum. The authors note this in their comments on the limitations of their study and on avenues for further research:

As we’ve noted previously [30], large-scale cross-sectional or ideally, longitudinal studies of cats maintained on different diets, utilising objective data, such as results of veterinary clinical examinations and laboratory data, as well as veterinary medical histories, should yield results of greater reliability, if sufficient funding could be sourced.

and we’re not destroying our planet in industrial livestock murder. Sounds great!

Comrade, I'm not trying to argue that cats are "obligate carnivores," or that cats should or should not have vegan diets. I'm not arguing about whether or not cats can meet their nutritional needs from vegan diets. I am only stating that the particular study linked does not provide any usable evidence in support of a conclusion. That's literally what "no reductions were statistically significant" means: that the collected data is not sufficient to draw reliable conclusions.

Other studies may very well have more rigorous methodologies that convincingly demonstrate the nutritional completeness of vegan diets for cats. But not this study.

LOL it's actually even lower if you look at Schedule J. Her base compensation is only 115,057. It's bonus and incentive comp (76,172) that brings it up.

Signal is not dependent on Google.

It literally is though.

191,229 USD

https://projects.propublica.org/nonprofits/organizations/824506840/202342569349300244/full

https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0284132

To study health outcomes in cats fed vegan diets compared to those fed meat, we surveyed 1,418 cat guardians, asking about one cat living with them, for at least one year. Among 1,380 respondents involved in cat diet decision-making, health and nutrition was the factor considered most important. 1,369 respondents provided information relating to a single cat fed a meat-based (1,242–91%) or vegan (127–9%) diet for at least a year. We examined seven general indicators of illness. After controlling for age, sex, neutering status and primary location via regression models, the following risk reductions were associated with a vegan diet for average cats: increased veterinary visits– 7.3% reduction, medication use– 14.9% reduction, progression onto therapeutic diet– 54.7% reduction, reported veterinary assessment of being unwell– 3.6% reduction, reported veterinary assessment of more severe illness– 7.6% reduction, guardian opinion of more severe illness– 22.8% reduction. Additionally, the number of health disorders per unwell cat decreased by 15.5%. No reductions were statistically significant. We also examined the prevalence of 22 specific health disorders, using reported veterinary assessments. Forty two percent of cats fed meat, and 37% of those fed vegan diets suffered from at least one disorder. Of these 22 disorders, 15 were most common in cats fed meat, and seven in cats fed vegan diets. Only one difference was statistically significant. Considering these results overall, cats fed vegan diets tended to be healthier than cats fed meat-based diets. This trend was clear and consistent.

Not to be a stick in the mud here, but... what? How on earth does "cats fed vegan diets tended to be healthier than cats fed meat-based diets" follow after "considering these results overall"? You mean the results that weren't statistically significant? Those results? And that one statistically significant disease difference? It was for kidney problems, and the vegan cats had more problems than the non-vegan ones (table 6).

If there's a case for feeding cats a vegan diet, this ain't it.

Law enforcement doesn’t request data frequently enough in order to build a social graph. Also they probably don’t need to as Google and Apple likely have your contacts.

They don't need to request data. They have first-class access to the data themselves. Snowden informed us of this over a decade ago.

Saying that it is somehow a tool for mass surveillance is frankly wrong.

Signal per se is not the mass surveillance tool. Its dependence on Google is the mass surveillance tool.

However, phone numbers are great for ease of use and help prevent spam.

And there's nothing wrong with allowing that ease-of-use flow for users that don't need anonymity. The problem is disallowing anonymous users.