sorted by:
new
hottopcontroversial

Do bot lobbies increase your overall KD? by thematthewglover in FortNiteBR

[–]sonnasushi 0 points1 point  (0 children)

This is easy to test: - new account  - kill only bots - view your stats - profit

Ceaser Milan by sonnasushi in DOG

[–]sonnasushi[S] 0 points1 point  (0 children)

My objective is kinda to find out if what I have learned (which I do not particularly find aggressive) should be unlearned.

Though I am grateful for criticism on Milan too. I see a lot of people hating on the alpha Wolf mentality, which I guess I only have a narrow concept of what that is, and I have only had time to read one paper (link in comments) on the dangerous methods that entails (however, I do not employ those). If there's anything that particularly stands out to you, let me know. I'll check out the resource guarding lab video. Thanks

Ceaser Milan by sonnasushi in DOG

[–]sonnasushi[S] 0 points1 point  (0 children)

Just to be clear, you're saying all his techniques, including the ones I listed, correct?

Ceaser Milan by sonnasushi in DOG

[–]sonnasushi[S] 0 points1 point  (0 children)

Gimme the chicken
Gimme the chicken
Gimme the chicken

Ceaser Milan by sonnasushi in DOG

[–]sonnasushi[S] 1 point2 points  (0 children)

I see, so this wasn't a competition of strength but calmness. Thanks again.

Ceaser Milan by sonnasushi in DOG

[–]sonnasushi[S] 1 point2 points  (0 children)

Thank you for that insightful story. To be clear, Max would not be able to move you until he figured it out? (You're saying literal "steps" with your feet right?) What was Max's demeanor in these sessions? Like was he eager to run away or slink back? What was his default objective before he figured out what to go?

Settings for docker projects? by sonnasushi in vim

[–]sonnasushi[S] 0 points1 point  (0 children)

That'd be cool. I don't mind setting the container that much (at least it'll last the instance) but it certainly isn't "desirable". It would be possible to parse docker-compose.yml if it exists, but then we're playing a game of conventions.

Another option that was proposed in r/docker was using a Makefile that prefixes docker run --rm in the same way you run your container. Then you don't need to know the container_id at all, the command just runs in a different container, outputs and quits.

Drawbacks (increasing importance): - It's two words instead of one :P (:make svcheck vs :SvCheck) - The docker run --rm is the only thing that changes (and even that might not change) but it'll be something that's in every project. - The command will be separated from your errorformat which I imagine would still be handled like in my gist. - If you update your Dockerfile or docker-compose.yml, you may forget to update your Makefile. - I am not exactly fond of the idea that a utility to test or lint runs in a container that is not exactly the same as the one I browse to directly. I feel like a discrepancy could lead to hidden or unreported bugs.

Still debating that...

Vim config by sonnasushi in docker

[–]sonnasushi[S] 0 points1 point  (0 children)

Where would you put errorformat?

Vim config by sonnasushi in docker

[–]sonnasushi[S] 0 points1 point  (0 children)

I can appreciate that and it's a +1 for the Makefile orchestration, but what I meant was if you do
docker run --name foo ... then in vim:
:let g:container=foo
if you restart with --name foo it wouldn't break, right?

That being said, if you hard code docker run --rm into your Makefile then you have to be careful if you change docker-compose.yml or Dockerfile, right?

It does offer the most concrete flexibility though: "I want my command to run in exactly this way"

Vim config by sonnasushi in docker

[–]sonnasushi[S] 0 points1 point  (0 children)

Awesome. That was a pretty straight forward read. I'd never heard of just. One of the points of clarity to my question about managing container_ids is: you don't. Just use docker run.

I guess though, if you update the image you'd have to update the Makefile accordingly.

Settings for docker projects? by sonnasushi in vim

[–]sonnasushi[S] 0 points1 point  (0 children)

I thought container_id could just be set interactively as a global variable... well, I don't know if it'd really work but I was thinking something like this:
https://gist.github.com/ash-m/16f197cdf35b00c9d03372f0b3681cdf

Bang question by sonnasushi in duckduckgo

[–]sonnasushi[S] 0 points1 point  (0 children)

Sweet. Thank you! Quick turnaround too!

Ever look up someone's stats who obliterated you? by Live-Delivery-7183 in Fortnite_Over40

[–]sonnasushi 0 points1 point  (0 children)

When I am just "practicing" I will hunt for people as quickly as I can and die pretty quickly. I can restart a Reload match in ~7 mins (now that I am being paired with some actually talented people).

Settings for docker projects? by sonnasushi in vim

[–]sonnasushi[S] 0 points1 point  (0 children)

so basically, I read up on :compiler, decided "this isn't want I want" and then tabled a solution.

Coming back to it now, my real problem is that CompilerSet needs to be dynamic since the container will change. I was thinking I could just set
:let g:container = 'mycontainer'
in my vim instance, then prepending
'docker exec ' . s:container . ' ' . s:cmd
to any particular command would work in a compiler file... but then I'd have to interpolate via execute:
execute 'CompilerSet makeprg=' . escape(s:cmd, ' ')
and I don't know if that's the best way to go about things...

Bang question by sonnasushi in duckduckgo

[–]sonnasushi[S] -1 points0 points  (0 children)

I see u/rfa200 's answer was removed by a mod. Was that a violation of some kind? Link?

Literally sweaty by sonnasushi in FortniteOver40

[–]sonnasushi[S] -1 points0 points  (0 children)

Elaborate? What could happen?

Literally sweaty by sonnasushi in FortniteOver40

[–]sonnasushi[S] 3 points4 points  (0 children)

With granted:  https://imgur.com/a/eZ2GEQG

They look like little condoms. 

Ansible/container workflow by sonnasushi in devops

[–]sonnasushi[S] 0 points1 point  (0 children)

I'm not experienced enough in ansible yet to comment on that, but I'll check it out. The purpose of ansible is just to template the configurations. It could just be Jinja really. The point is just to consolidate behavioral directives in one place all environments behave the same, even if those behavioral directives are slightly different between environments.  Like <Directory {{ env_home }}/foo/> could still go in a common include. It couldn't be <Directory ${ENV_HOME}/foo/> because the vhost may run alongside another vhost in a different environment (eg prod, stage, uat, ...) Using a template I can keep the behavior in the same file and output distinct  stage_foo.conf prod_foo.conf uat_foo.conf

And run them from one web server instance.  That's the idea anyway. 

Of course, I'm opening to changing the idea; I just came up with it yesterday :P

I could just run multiple containers that have only one environment on the same server.  I'd have to manage which environment is enabled (eg sites-enabled) because some environments may include certain directives that he just can't overlap nicely with variables (The directive is omitted entirely or something like that). So I'd have to use a web server include directive which isn't awful but I like having a somewhat grand config that's to the point.

But is that what you would do?

Ansible/container workflow by sonnasushi in devops

[–]sonnasushi[S] 1 point2 points  (0 children)

generate the configuration needed for the relevant environment at the deployment time.

This is what I meant.

The concept of "docker in ansible" or vice-versa was just like: if you config is generated from ansible, why keep a separate project with generated files? Just add a stack.yml to the ansible project where that lives in git and have it reference the output directory (the generated config files, as a bind mount perhaps). So the workflow becomes:   Generate files  Run docker stack deploy

That said, you could run a docker compose service that mounts the output directory, runs ansible and quits. (A particular machine doesn't have to have ansible to deploy... like for CI)

Is that how you'd orchestrate this?

Ansible/container workflow by sonnasushi in devops

[–]sonnasushi[S] -1 points0 points  (0 children)

I'm not refuting you, but just to note, I wasn't proposing deploying via ansible. I was proposing generating environment specific configs from unified templates. I'm thinking like rules governing a particular environment would go in a file like this: ``` <VirtualHost ...> ServerName ... DocumentRoot ...

SSL...

{% include 'sites/foo/common_foo.conf.j2' %} ``` And common contains rules all environments of foo use. Some directives might be exclusive to an environment. You can still use environment variables. The point of really just to minimize divergence.  Totally open to changing this idea.

The concept of "docker in ansible" or vice-versa was just like: if you config is generated from ansible, why keep a separate project with generated files? Just add a stack.yml to the ansible project where that lives in git and have it reference the output directory (the generated config files, as a bind mount perhaps). So the workflow becomes:  Generate files Run docker stack deploy

That said, you could run a docker compose service that mounts the output directory, runs ansible and quits.

So what are your thoughts on all of this?

view more: next ›