anonacct37

What I think is funny is that circa 2008 I had a manager who used to work at Amazon who told me that "a surprising amount of Amazon artificial intelligence is artificial artificial intelligence, low paid workers".

I heard this was behind mechanical turk. Sounds like the playbook remained the same.

I really think that they bury the lede:

> As a setuid program meant for elevating privileges, all code that is compiled into sudo-rs has the potential to accidentally (or intentionally) give access to system resources to people who should not have that access. The setuid context additionally puts some constraints on how code is executed, and dependencies might not have accounted for that context. We could not expect any of our dependencies to take into account such a context either.

This is the real problem. I've come to the conclusion that setuid programs basically shouldn't be using most libraries. The setuid environment is just fundamentally different. A normal library can have a debug output file who's location is controlled by an environment variable without that being a security risk. But the instant that program becomes setuid, that's an arbitrary file overwrite security bug. Most libraries aren't built with that in mind. They shouldn't have to be. Setuid is poorly designed.

I used it and even took a class taught by salt stack employees.

I really was not a fan. I think one of the core problems I ran into was that the tool attempted to layer on rpc behavior to what was fundamentally a broadcast.

So you'd apply something to everything with a web role. The tool would attempt to make it appear as if you executed apply on n nodes and return after n responses. But since this was all just a broadcast what really happened is the tool dropped a message on the bus and then guessed how many responses it would get. If it guessed wrong the cli invocation would just hang.

I'm not sure if I follow but it does occur to me that being thrifty and changing from a aerospace engineering company to a financial engineering company can be two different things that might end up categorized as "accountants are in control".

This is a very sharp tool and I find it's really rare to need it.

I do alot of profiling and performance optimization. Especially with go. Allocation and gc is often a bottleneck.

Usually when that happens you look for ways to avoid allocation such as reusing an object or pre allocating one large chunk or slice to amortize the cost of smaller objects. The easiest way to reuse a resource is something like creating one instance at the start of a loop and clearing it out between iterations.

The compiler and gc can be smart enough to do alot of this work on their own, but they don't always see (a common example is that when you pass a byte slice to a io.Reader go has to heap allocate it because it doesn't know if a reader implementation will store a reference and if it's stack allocated that's bad.

If you can't have a clean "process requests in a loop and reuse this value" lifecycle, it's common to use explicit pools.

I've never really had to do more than that. But one observation people make is that alot of allocations are request scoped and it's easier to bulk clean them up. Except that requires nothing else stores pointers to them and go doesn't help you enforce that.

Also this implementation in particular might not actually work because there are alignment restrictions on values.

Going on 5+ years using a single giant org file. It's the only system I've ever been able to stick with for more than a couple days.

I think of it as my labbook.

I love and hate this. On a visceral level I don't like dealing with issues via malicious compliance.

OTOH I absolutely agree this is a good call if your goal is for more users to be able to run more software on your platform, even if printing is broken.

I do like this about go. And on Linux it arguably makes sense (I say arguable because DNS without CGO is still a common cause of issues and incompatibility).

But Linux has, to the best of my understanding said "yes, we are ok with users using syscalls". Linux doesn't think that glibc is the only project allowed to interface with the kernel.

But for other platforms like OpenBSD and windows they are quite simply relying on implementation details that the vendors consider to be a private and unsupported interface.

This whole thing is also separate from "is making libc the only caller of the syscalls instruction" a good and meaningful security improvement.

Android has a BLE scanner app that can passively read info. I don't know enough about the protocol to know if that is the same thing you are referring to.

No memory leaks (unless you use shared memory). No weird connection pooling and caching issues or delays in picking up a config change. Every request is a fresh start, enforced by the OS. Buggy code (like image processing can only crash the current request).

The actual damage is that it's pretty common (my last team has this happen) for a team to setup a cert, verify it works, and then when they deploy the cert it works some of the time or "works on my machine" and so the failures seem really random and by definition hard to reproduce because you have to restart chrome to reproduce.

Probably the tl;Dr is that validating against a persistent cache like Firefox is fine. Validating against an ephemeral cache with chrome is likely to cause a lot of breaking.