1. Docker (or any Linux container runtime, for that matter) is not intended for, designed for, or effective as a security boundary.
2. Root containers run as root on the host. The "sandboxed" processes have full capabilities, as far as the kernel is concerned with them.
ProxyCommand allows you to use any command to setup a connection. Not necessarily an ssh command, like ProxyJump. It can be any command, as long as it receives on stdin and produces on stdout, it can act like a TCP connection.
ProxyJump is a special case of `ProxyCommand ssh -p <port> <user>@<host>`. Can't replace the `ssh` in there when using ProxyJump.
> you could do ca. 1200 prompts per double decker. Which is a lot.
If humans had evolved to do prompts (while retaining everything else that makes human thought human), that number doesn't sound that big.
OTOH, if LLMs had to do everything humans need energy for, that number would be waaay too big for LLMs.
----
Humans don't even have an efficient energy input system. How many of those 1.3M joules actually get assimilated? Silicon is a lot more efficient at energy, because a lot of effort has been put into making it so, and is fed raw energy. It doesn't need to process food like humans, humans already did that for it when they captured the energy in electricity.
----
I'm sure there's more ways of making the comparison more fair, but I doubt your parent was trying to prove their claim with such deep research. So let me try another angle: No human can burn through as much energy as the top hosted LLMs do for one prompt, in as much time.
> a vowel when it's between two consonants, and a consonant when it's not.
Not a hard rule, honestly.
Some Indian languages exhibit a blurring of sorts with Ye- sounds. E.g., in Telugu, the word for 'How' is 'yela', which is often also pronounced as 'ela'. TBF, Telugu also blurs Ve-/We- sounds similarly.
I belong to the class of people who believe in customising their tools as they please. So I'd have written an Emacs package to do this. But then again, this is Emacs, so someone's probably already done it. Oh, here it is: https://github.com/mooreryan/markdown-dnd-images
> bunch of hacks, such as containers, which are cumbersome to use. Firefox's "solution" forces you to switch Github tabs between personal and work containers constantly.
Rarely have I had to that. Until I added rules to open certain URLs in specific containers.
> Chromium provides separate windows with different profiles, and Firefox should follow Chromium here.
Absolutely not. Profiles are a poor "alternative" to containers. How do I add a rule to pin URLs to specific profiles? How would that even work, if it did? A new window for some links? Re-use some random window with the same profile? How do I switch to it? Switch back? Don't tell me to use the Window Manager via Alt-Tab. I organise tabs into windows by shared context.
Then there's the whole issue of sync. Profiles don't share anything. Each profile needs to be configured individually. I like not having to add uBlock Origin to every browser profile. I like not having to think if I have my password for this rarely visited site in this profile or another one. Or a bookmark. Or form info.
----
Just because containers have no use to you / you couldn't find a use for them, doesn't mean the rest of us also shouldn't have the luxury of using this feature. Feel free to use Profiles as you'd like. Leave what works for us alone.
So, morality isn't a concern as long as you get something out of it, got it.
Too bad all you're gonna get is a botched and broken nation and years of misery, but that shouldn't matter as long as you get "something for my money".
And you're sure you're gonna get "something for my money" with people that make no attempts to even veil their corruption and lawlessness. Right? Say, are you, by any chance, "rich"? I mean, rich enough to be considered rich by the oligarchs, that is.
That can't be true. Now, I haven't used Outlook myself, but I've received enough garbage from that godforsaken relic of a time when MS wanted to EEE email to know that that can't be true.
FWIW, I've posted patches to the PG mailing list just fine with GMail. The web app, that is.
This is correct. My use-case was safe with eventual consistency, so I could've even used `synchronous_commit=off`, but I kept it to 'local' to get a baseline. Was happy with the 60k number I got, so there was no need for 'off'.
But I think the biggest reason I hit that number so easily was the ridiculous ease of batching. Starting with a query to select one task at a time, "converting" it select multiple tasks instead is ... a change of a single integer literal. FOR UPDATE SKIP LOCKED works the same regardless of whether your LIMIT is 1 or 1000.
> ... making sure that objects are placed into exactly 1 batch. curious if you ran into any bottlenecks there?
A single application-layer thread doing batches of batch creation (heh). Not instant, but fast enough. I did have to add 'batchmaker is done' onto the 'no batch left' condition for worker exit.
> ... that pushes the locking from selecting queue entries to ...
To selecting batches. A batch is immutable once created. If work has to be restarted to handle new/updated objects, all batches are wiped and the batchmaker (and workers, anyway) start over.
I hit 60k per second in 2020 on a 2-core, 100GB SSD installation of PG on GCP. And "tuning" PG is way easier than any dedicated queueing system I've seen. Does there exist a dedicated queueing system with an equivalent to EXPLAIN (ANALYZE)?
I did sth similar. Designed and built for 10 million objects / hour. Picked up by workers in batches of 1k. Benchmark peaked above 200 million objects / hour with PG in a small VM. Fast forward two years, the curse of success strikes, and we have a much higher load than designed for.
Redesigned to create batches on the fly and then `SELECT FOR UPDATE batch SKIP LOCKED LIMIT 1` instead of `SELECT FOR UPDATE object SKIP LOCKED LIMIT 1000`. And just like that, 1000x reduction in load. Postgres is awesome.
----
The application is for processing updates to objects. Using a dedicated task queue for this is guaranteed to be worse. The objects are picked straight from their tables, based on the values of a few columns. Using a task queue would require reading these tables anyway, but then writing them out to the queue, and then invalidating / dropping the queue should any of the objects' properties update. FOR UPDATE SKIP LOCKED allows simply reading from the table ... and that's it.
Yes, now you get my point. Do you run rootless containers (with the Docker backed) or do you run "root" containers?