For context for other readers: this is referring to NAT64. NAT64 maps the entire IPv4 address space to an IPv6 subnet (typically 64:ff9b). The router (which has an IPv4 address) drops the IPv6 prefix and does a normal IPv4 NAT from there. After that, you forward back the response over v6.

This lets IPv6 hosts reach the IPv4 internet, and let you run v6 only internally (unlike dual stack which requires all hosts having v6 and v4).

It’s not complicated until your reputation drops for a multitude of reasons, many not even directly your fault.

Neighboring bad acting IPs, too many automated emails sent out while you were testing, compromised account, or pretty much any number of things means everyone on your domain is hosed. And email is critical.

git commit -a --amend

It looks like on blender’s website there’s 6 entities on there, and one of them does seem to be an individual fwiw. Here’s his website: https://aras-p.info/.

The rest all seem to be corporations though - meta, aws, some game company I’ve never heard of, AMD, and epic.

I just checked their financial report for 2022 and it looks like 50% came from patron funding (which looks like entirely companies like Google), 5% from epics grant, and then 10% corporate membership. 20% came from individuals, and the rest from random other miscellaneous things like the blender market. If you search blender foundation annual report 2022, the finances breakdown will be near the end of the slides.

Wikimedia foundation is, none of the other things I listed are.

I think the key there is funding from big companies. There’s tons of standards and the like in which big companies take part - both in terms of code and financial support. Big projects like the rust compiler, the Linux kernel, blender, etc. all seem to have a lot of code and money coming in from big companies. Sadly there’s only so much you can get from individuals - pretty much the only success story I know of is the wikimedia foundation.

The point is to minimize privilege to the least possible - not to make it impossible to create higher privileged containers. If a container doesn’t need to get direct raw hardware access, manage low ports on the host network, etc. then why should I give it root and let it be able to do those things? Mapping it to a user, controlling what resources it has access to, and restricting it’s capabilities means that in the event that my container gets compromised, my entire host isn’t necessarily screwed.

We’re not saying “sudo shouldn’t be able to run as root” but that “by default things shouldn’t be run with sudo - and you need a compelling reason to swap over when you do”

Yeah. There’s reasoning for why they do it on their docs, but the reasoning iirc is kanidm is a security critical resource, and it aims to not even allow any kind of insecure configuration. Even on the local network. All traffic to and from kanidm should be encrypted with TLS. I think they let you use self signed certs though?

Kanidm doesn’t require a CA, it just requires a cert for serving https (and it enforces https - it refuses to even serve over HTTP). I think that was just the OP not quite understanding the conceptual ideas at play.

Kanidm wants to directly have access to the letsencrypt cert. It refuses to even serve over HTTP, or put any traffic over it since that could allow potentially bad configurations. It has a really stringent policy surrounding how opinionated it is about security.

The last bit isn’t strictly true - there’s ways to trace such tasks by generating IDs and associating it per task / request / whatever, letting you associate messages together even in a concurrent environment. You can’t just blindly print but there’s libraries and the like to help you do it.

Right, but when there’s third parties involved which you may not trust (which is almost always going to be the case when talking to users not on your server), e2e’s benefit starts becoming a lot more enticing. And while you have a point on out of band key sharing being annoying, it makes sense as a default - especially when content is going across servers. Content should be secure with an opt-out rather than insecure with an opt-in. The latter is just more error prone.

Also: while it’s not friction free, apps like signal have shown that you can get verified e2e to be usable for the general population.

I don’t think the SATA acronym is right…

The point of federation means your content doesn’t only stay on your server. The person you’re talking too can be on a different one and their admin can see them too. Also, I wouldn’t want to be able to access content from any user - it’s a “no trust needed” thing.

Because I associate an OS with more then just an environment. It often has several running apps for instance, often a GUI or shell (which many containers don’t have), are concerned about some form of hardware (virtual or physical), and just… Do more.

Containers by contrast are just a view into your filesystem, and some isolation from the rest of the environment through concepts like cgroups. All the integrations with the container host are a lot simpler (and accurate) to think of as just simply removing layers of isolation, rather then thinking of it like its own VM or OS. Capabilities just fit the model a lot better.

I agree the line is iffy since many OS’s leave out a few things of the above, like RTOS’s for MCUs, but I just don’t think it’s worth thinking of a container like its own OS considering how different it is from a “normal” Linux based OS or VM.

I think the more intuitive model (to me) is instead of thinking of it as a lightweight virtual machine, or a neatly packaged up OS, is to instead think of it as a process shipped with an environment. That environment includes things like files and other executables (like apt), but in of itself doesn’t constitute an OS. It doesn’t have its own filesystems, drivers, or anything like that. By default it doesn’t run an init system like systemd either, nor does it run any other applications other than the process you execute in the environment.