Preston Maness ☭

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.

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.

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.

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

We must be hanging around different humans.

Absolutely not, and this article goes into quite a few reasons why:

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

Sadly there’s reality. The reality is to get away from the evil distributions the Flatpak creators have made… another distribution. It is not a particularly good distribution, it doesn’t have a decent package manager. It doesn’t have a system that makes it easy to do packaging. The developer interface is painfully shoehorned into Github workflows and it adds all the downsides of containerisation.

While the developers like to pretend real hard that Flatpak is not a distribution, it’s still suspiciously close to one. It lacks a kernel and a few services and it lacks the standard Linux base directory specification but it’s still a distribution you need to target. Instead of providing seperate packages with a package manager it provides a runtime that comes with a bunch of dependencies.

If you need a dependency that’s not in the runtime there’s no package manager to pull in that dependency. The solution is to also package the dependencies you need yourself and let the flatpak tooling build this into the flatpak of your application. So now instead of being the developer for your application you’re also the maintainer of all the dependencies in this semi-distribution you’re shipping under the disguise of an application. And one thing is for sure, I don’t trust application developers to maintain dependencies.

Even if there weren’t so many holes in the sandbox. This does not stop applications from doing more evil things that are not directly related to filesystem and daemon access. You want analytics on your users? Just requirest the internet permission and send off all the tracking data you want.

Developers are not supposed to be the ones packaging software so it’s not hard at all. It’s not your task to get your software in all the distributions, if your software is useful to people it tends to get pulled in.

Another issue is with end users of some of my Flatpaks. Flatpak does not deal well with software that communicates with actual hardware. A bunch of my software uses libusb to communicate with sepecific devices as a replacement for some Windows applications and Android apps I would otherwise need. The issue end users will run in to is that they first need to install the udev rules in their distribution to make sure Flatpak can access those USB devices. For the distribution packaged version of my software it Just Works™

I don’t think Red Hat is violating GPL. For sure it’s not violating the legal terms of it (I’m fairly certain the army of lawyers RH and IBM have at their beck and call made sure of that) and I don’t think it’s violating it’s spirit (at least not yet) – they are still contributing any changes and their customers still get access to the source code.

They are absolutely violating the spirit of the GPL. Telling your customers that you will not keep them as customers if they exercise their rights under the GPL is as clear a spiritual violation as it gets. And whether they are violating the letter of the law is an unresolved question.

The way I see it, RH wants to be the only game in town providing service contracts for their own product which is fair game, imho. The problem with Rocky is that they also stand to make money out of the same source code which is the disingenuous part, in my opinion.

The problem is that the software is not “their product.” Free Software is a collective endeavor that RedHat contributes to. It is not a product that belongs to them. The product is the support, and RedHat, by virtue of the GPL and the nature of Free Software, cannot stake an exclusive claim to the support.

While I disagree with Red Hat’s decision to hinder source access, this move from Rocky (a commercial company!) seems even more disingenuous, imho.

Why on earth is it disingenuous? RedHat is openly stating its intent to violate the GPL. Rocky is telling them “good luck with that.” RedHat wants to be the only game in town providing service contracts. Rocky is saying “no thanks; we’re sticking around.”

systemd is a godsend when you need service control while getting actual work done, at scale.

there are legitimate things to criticize but in general the rants are incompetent preaching to the uninformed.

Service control was systemd’s main benefit and what it most excelled at. Having shell scripts for everything was a legitimate pain. It was all the other pieces of the ecosystem that it was wanting to subsume that got people upset (logging, cron, time, hostname, login, etc). Journald/binary logs was the main sticking point that I recall, though I figured it was a trade-off that was worth it, especially since you could have journald keep dumping to text anyway.

I use Kagi:

https://kagi.com/

You gotta pay for it, but I’ve found it worth paying for so far.