airocker

6 ms·

31.
by airocker 1y ago
but dont they have overlapping requirements of solving "not works on my machine"
32.
by airocker 1y ago
Would love to hear nix people take on this?
33.
by airocker 1y ago
I want to bet 10 million that this won’t happen if anyone wants to go against my position. Best bet ever. If i lose, i don’t have to pay anyways.
34.
by airocker 2y ago
They could use vitess, citus or alloydb. They could use read replicas for read operations and single master in a shard for write. They would get many SQL features (upgrades, referential integrity etc) for free. It would allow them to extend
35.
by airocker 2y ago
Just wondering if anyone considered using Postgres or another relational db. I understand it won’t do multi master replication as well but it is much more stable and predictable if you give it right amount of traffic. I guess the team had t
36.
by airocker 2y ago
Is there a registry that would work on extremely cheap disk storage if the use case if only push and very infrequent pulls?
37.
by airocker 2y ago
RIP. She should be credited when someone at OpenAI introduces the concept of hormones to neural networks.
38.
by airocker 2y ago
We use a garbage collector to error restart if a job is not served within a specified amount of time.
39.
by airocker 2y ago
We use a garbage collector to error restart if a job is not served within a specified amount of time.
40.
by airocker 2y ago
Great observation, I wrote a little wrongly. What we want ideally is guaranteed delivery to one random free worker. Uuid strategy is better than locking but this could mean that if one worker gets a longer job, all the others on this worke
41.
by airocker 2y ago
Thats exactly what we do but taking a lock takes 1 RTT to the database which means about 100ms. it limits the number of events receivers can handle. IF you have too many events, receivers will be just trying to take a lock most of the time.
42.
by airocker 2y ago
We use listen notify extensively and it is great. The things it lacks most for us is guaranteed single recipient. All subscribers get all notifications which leads to problems in determining who should act on the message n our case.
43.
by airocker 2y ago
A different take: All companies are built on relationships. Large companies are a form of nepo companies where you get paid for a relationship to the management chain.
44.
by airocker 2y ago
This is so true! Going after the pie in the sky only works for a short while, then you have to work for your pie. the worst is that employees in windows used to get slower promotions than these new tech groups (live,mobile etc ) which mean
45.
by airocker 2y ago
I think dbs like etcd mongo Postgres all have some notion of events and notifications. The only drawback is that you have to still poll from the ui if you use these. This is sufficient for most use cases. If you want real time updates, Kafk
46.
by airocker 2y ago
If we forget how the current system is architected, we are looking at two problems: First problem is that Linux capabilities are also dealing with isolating processes so they have limited capabilities because the user based isolation is not
47.
by airocker 2y ago
I think it will be better if you create events automatically based on commit events in wal.
48.
by airocker 2y ago
Good software hides complexity. User does not have to understand user group permissions suid etc etc
49.
by airocker 2y ago
I think a admin would better understand the system if there was only one subsystem doing a particular type of security and not two. Two subsystems doing security would lead to more problems down the road.
50.
by airocker 2y ago
no it is not
51.
by airocker 2y ago
It could all be simplified and map one to one to your identity provider credentials at a higher level. Having a complicated user system on the servers makes it a problem.
52.
by airocker 2y ago
One user with sudo for sysadmins on baremetal and a sudo access without CAP_SYSADMIN on container should be good.
53.
by airocker 2y ago
Exist does not mean it should keep existing if it is unnecessary complexity from the past.
54.
by airocker 2y ago
You dont need to use docker. Containerd or just just direct cgroup manipulation: https://access.redhat.com/documentation/en-us/red_hat_enterp...
55.
by airocker 2y ago
but then even traditional multi-user would be compromised in this case.
56.
by airocker 2y ago
In an on-prem cluster, yes one guy or a few sysadmins who either share passwords or can somehow put their keys in the authorized keys file and ssh. In the cloud, AWS/GCP let or not let an IAM user reach a server.
57.
by airocker 2y ago
Only one human per machine. If you need to share the machine, make multiple containers and give everyone a separate container.
58.
by airocker 2y ago
How about only in servers where you only have CPU/Memory/disk/GPU with open source trusted drivers?
59.
by airocker 2y ago
you could potentially create multiple containers in that machine which are single user and give to every user who needs access. CPU/Memory/GPU can be assigned in any way you want(shared/not shared). Now no user can mess up an
60.
by airocker 2y ago
There have been no big cves of container escapes for a while now. I guess it can be considered secure enough.

More ›