The amount of syscalls in Plan9 is so small that pledge(2) wouldn’t make much sense. And unveil(2) wouldn’t really be necessary as there are already mount namespaces, a process can unmount paths and then use rfork(2)s RFNOMNT flag to disallow mounting new resources.

https://swtch.com/~rsc/talks/nauth.pdf

I learned about monads via Maybe in Haskell; the equivalent in Rust is called Option.

Option<T> is a type that can hold something or nothing:

enum Option<T> {
    None,
    Some(T),
}

Rust doesn’t have null; you use option instead.

Options are a particular instance of the more general Monad concept. Monads have two important operations; Haskell calls them “return” and “bind”. Rust isn’t able to express Monads as a general abstraction, and so doesn’t have a particular name. For Option<T>, return is the Some constructor, that is,

let x = Option::Some("hello");

return takes some type T, in this case, a string slice, and creates an Option<T>. So here, x has the type Option<&str>.

bind takes two arguments: something of the monad type, and a function. This function takes something of a type, and returns an instance of the monad type. That’s… not well worded. Let’s look at the code. For Option<T>, bind is called and_then. Here’s how you use it:

let x = Option::Some("Hello");
let y = x.and_then(|arg| Some(format!("{}!!!", arg)));

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

this will print Some("Hello!!!"). The trick is this: the function it takes as an argument only gets called if the Option is Some; if it’s None, nothing happens. This lets you compose things together, and reduces boilerplate when doing so. Let’s look at how and_then is defined:

fn and_then<U, F>(self, f: F) -> Option<U> 
where F: FnOnce(T) -> Option<U>
{
    match self {
        Some(x) => f(x),
        None => None,
    }
}

So, and_then takes an instance of Option and a function, f. It then matches on the instance, and if it’s Some, calls f passing in the information inside the option. If it’s None, then it’s just propagated.

How is this actually useful? Well, these little patterns form building blocks you can use to easily compose code. With just one and_then call, it’s not that much shorter than the match, but with multiple, it’s much more clear what’s going on. But beyond that, other types are also monads, and therefore have bind and return! Rust’s Result<T, E> type, similar to Haskell’s Either, also has and_then and Ok. So once you learn the and_then pattern, you can apply it across a wide array of types.

Make sense?

It’s also related to the standard library itself having lots of globals. Which itself leads to bad things, like the cryptographic randomness source being trivially modifiable: https://github.com/golang/go/issues/24160

The Go community has a strong culture of writing application-specific code that is “good enough”, and tends to err strongly on the side of avoiding premature abstraction. For a significant number of use cases, globals (combined with a reasonable amount of documentation, testing, and good discipline) tend to be the “good enough” solution.

The thesis of Go’s culture is that premature abstraction often costs more than rewriting code. The argument is that you often know your domain better after writing a “good enough” first version, and that premature abstractions lock you in to specific designs more tightly that may be harder to change down the line.

It’s definitely not a conventional position, but it’s not indefensible – it’s hard to argue that Go developers are not pragmatic (or not productive).

Interesting. Good to know!

Meanwhile, in Firefox, you can just click the checkbox to disable automatic updates in the add-ons manager (either globally or for a particular add-on).

They also seem to have a pretty decent review process for add-ons; I don’t know whether they’d catch malicious updates, but when I submitted my add-on, I got actual technical feedback about the code (like a suggestion to replace innerHTML with textContent on a particular line).

With how great Firefox Quantum is these days, maybe it’s time to consider switching?

A power user can always download the extension’s source code and install it separately in developer mode. Since that counts as a different “extension” than the one offered in the store, it won’t automatically update.

I’m probably in the minority here, but I think automatic updates as a default is a good idea. Ideally there would be a way to turn this off, but defaulting to automatic updates is better than defaulting to manual updates. The vast majority of updates fix real bugs and the vast majority of users won’t update manually.

No, I specifically want a better cut of the value that I produce.

If I grow sales by 5x by implementing a feature, there are some options, right?

• Others who failed to grow sales are penalized
• Others who failed to grow sales are penalized and their rewards given to me instead
• Everybody gets a cut of the sales, even Frank the sales guy who sucks and Ann the janitor who does the same amount of work day in and day out cleaning toilets
• I get no compensation (compared to base case of not succeeding)
• I get compensated by small bonus
• I get a percent of the sales increase

Only two of those aren’t terrible. Only one of them is fair.

If you want to see a developer act do work that can bring in 10 million, cut them in for 5%. I can’t think of any dev who wouldn’t move heaven and earth to make 500K in a year.

Of course, the current system is more a deal of “You’re lucky to have a job here, here’s the salary, management/shareholders will skim off the profits that, by construction, they themselves could not have realized had you (or devs like you) agreed to it.”

And honestly, while I respect the problems of folks who aren’t in our industry making our wages, I also work very hard not to have those problems. I have no desire to be holding the bag when market trends correct themselves and we’re paid the same as non-devs while the people we let fleece us are fucking off in their Teslas to Moneyland.

A big part of this is probably the existence of copyleft licenses which provide a legal mechanism to guarantee that continued work will be contributed back to the community. I wonder if a similar mechanism exists for artists (perhaps creative commons?).

It’s also important that software has a useful notion of “contributing back to the original work”, and that contributing is both standardised (my copy of git and the language compiler probably works the same as yours) and idiomatic (diffs, patches, and PRs are all well-known tools). It seems possible in theory to have large, open source, collaborative design projects (where many designers contribute back to a single project under copyleft terms), but I’m not aware of a “standard” design format with both a critical mass of users and good support for decentralised contributions.

I think free work should be discouraged if someone else is profiting. However if it such a taboo because they have a history of being abused and low quality of life perhaps we should start an money pool to pay for contributors who don’t have a higher paying job like software development.

Funny because the android OS gets a LOT of contributions. Just because something is novice friendly doesn’t mean it has to be crippled in any way. Also there’s a lot of unique and interesting challenges in making a user friendly operating system.

I’m trying to avoid executing setup.py files downloaded from the internet on the Libraries.io servers

That’s wise - I’ve seen all sorts of shenanigans in those files. Just importing some of them causes attempted sudo operations.

I’m not particularly familiar with the python world, but this sounds like the perfect use-case for containers, no?

Note I said containers not “docker”. I believe what you want is a quick “spin up $distro, install $package, analyse installed deps” flow, which imo would suit lxc/lxd perfectly.