u/RulerOf

Oh you're probably right. I read this:

It is only considered "cast from your hand" if you cast it as a spell from your hand. Putting it onto the battlefield from your hand using a spell or ability will cause you to lose the game.

But saw it just as a caveat and didn't think about it any harder. I just love the potential for that interaction due to timing.

If you're targeted with this ability in a 1v1, you absolutely should cheat out [[Phage, the Untouchable]] with it.

Troi's controller's Phage copy will be on the stack on top of yours, will enter the battlefield first, and they will lose the game before you do.

You can possibly fix it with a stupid-bright television with a good anti-glare coating.

Pretty much.

What I'd suggest:

• If you have multiple accounts in AWS Organizations, go to the management account. If you don't, skip this step.

• Go to the Identity Center console and set up SAML.

• Create a single admin user for yourself. If your org is small you can do this on easy mode and just set the username to the email address.

• Create a permission set named AdministratorAccess, and then add the AdministratorAccess managed policy to it.

• Create a group named Administrators. Add yourself to that group. Apply the permission set to that group.

• Sign yourself in through SSO. See how it works.

• Add more permission sets for different roles. You can attach your own IAM policies or create inline ones.

• Create groups for those roles. Attach the permission sets to them.

• Create users for those groups. Add the users to the groups.

If you're really well organized and/org have a very large org, consider setting up automatic user provisioning—but TBH if you're small I wouldn't bother. I'd prefer to assign users in the AWS console rather than delegate it to HR or whoever and have that security boundary operated outside of AWS.

Also, don't forget to refer to the docs. I'm giving a high-level overview from having done this a few times. Also ChatGPT or Claude are your friends with this one.

Good luck.

Edit: Oh, one more thing. Every time you create a permission set, apply it to your admin group. This will let you test it easily.

If you're creating regular IAM users and those users log in on console.aws.amazon.com with your account number/alias + username + password, then IAM Identity Center won't affect it at all. Those IAM users will continue to function until you delete them.

Set up identity center with SSO. Give users a week to transition to it, then shut the IAM accounts off.

Users will lose their AWS landing page customizations, but so long as their permission set contains the same permissions their IAM user had, it'll be a drop-in replacement for them.

/u/safihre BTW do you take feature requests? I'd love to be able to create multiple NZB/Admin API keys and tag each with a note.

Plenty of reasons have high-security workarounds (like using a VPN), but my personal reason for public access is that I like using the send-to-SAB feature on indexers. This makes a synchronous, authenticated request back to my SAB to start a download—and I know I could use an RSS cart, but I don't like that it's based on polling.

I use IP whitelisting plus auth for most access, but gate this stuff in the reverse proxy by validating the API key in the request before passing requests back to SAB to minimize surface area.

I was stuck on a 2.4 or 2.5 version and couldn't complete upgrades either. Tried it a few times and each time ended up restoring VM snapshots.

I would export the old-config.xml, install a new one fresh, then export the fresh upgrade-config.xml with just interfaces assigned.

You can try to apply the old XML export to the new machine, and if it doesn't work, throw both at an AI agent and ask it to construct a valid one for the new version with the settings from the old one. After you apply it, look around the web UI and validate things.

I've always proxied my NZB downloads. For years. Even though it's a lot slower that way. I want the metrics in Hyrda and you have to do that to get them.

Never gotten an email like this from any of the indexers.

It utilizes the tuned.conf geared for virtual-guest usage:

https://docs.vyos.io/en/rolling/configuration/system/option.html#performance

Check content of /usr/lib/tuned and you will see the profiles thats included with tuned.

I sorta get that, but my only problem was that the docs don't include the options I actually see. The docs pages covers throughput and latency modes, but not any of the others that show up in the CLI:

vyos@drew-edge# set system option performance
Possible completions:
   network-throughput   Tune for maximum network throughput
   network-latency      Tune for low network latency
   power-save           Tune for low power consumption
   virtual-guest        Tune for running inside a virtual machine
   virtual-host         Tune for running guest virtual machines

This one intrigues me:

set system option performance 'virtual-guest'

But it seems to be completely undocumented. Would love to know what it's supposed to do.

One level was flying the Millennium Falcon through some sort of canyon or internal superstructure.

Any chance you're talking about the ROTJ SNES game?

I had a dream of creating a tool that you would feed a plan output JSON to along with a set of YAML declarations of exactly which resources were allowed to churn for a given plan.

I never wrote it.

Could probably vibe code it though.

You put a modern BBS app on an 800 number? Nice.

Hi Kita.

I poked my account rep about it yesterday and we've done a round of back-and-forth. You still want the case number?

I opened a request to switch to Net30 billing nearly two weeks ago. It's still unassigned.

Although I mentioned Bedrock in the ticket, so maybe that's why nobody has picked it up 🥲

Taking Over Me was the song that got me to go beyond the singles (specifically the v2 demo).

Cloud Nine was the other song I really got stuck on for quite a while.

I've been to roughly 8 concerts in the last 9 years. Never seen either of them live 🥲

Oh for sure. I added NVMe to the same X58 system by just getting one of those thumb drive header adapters and booting Tianocore—but to be clear I find the option rom technique you used much more compelling, because it's more correct to the actual underlying firmware :)

I'm only bringing up the BIOS modding route because it's extra cool to do a BIOS mod 🤣

I wish I had documented it, but ages ago I used BIOS modding tools (AFAIK it's literally the vendor utilities from AMI or whoever) to install an iPXE ROM directly into my BIOS image file for my Gigabyte GA-EX58-EXTREME motherboard.

If the payload is small enough, I'd bet the same trick could be pulled off with the Kittenlabs image. Have you looked into anything like that?

No. I've been writing with emdashes for quite some time, especially on Reddit.

I had a bit about how they were looking for an architect at a sysadmin price but I left it out.

The important takeaway—which TBH I don't think I really got to, sorry—is that when nobody takes charge of driving the conversation, as happened to you today, everybody leaves frustrated or disappointed.

The onus is of course on the interviewers to bring the structure to the process—they're the ones that truly showed up unprepared.

However... it's tired advice by now, but try to remember you're selling yourself in the interview. If you can, steer the conversation in a way that lets you display how you can solve their problems. Opinionated workflows drive everything in tech, and yours is one of the things you can sell here.

Consider the NFS mount again, make the answer infrastructure driven:

• add a mount in the playbook for the webservers to point /var/www to the NFS endpoint
• validate the mount with tests run in molecule
• Apply that in tower (or whatever) to the servers

Maybe that's stuff they already know, but suppose it isn't: give them the chance to ask why you'd do it that way. Explain the value of testing changes and promoting code through stages. There's no real followup to "I'd add an entry to /etc/fstab" but there absolutely is one to "I'd use this ansible-driven process."

I had "the guy" do that once shortly after the start of an interview. He laughed at something I said, but not in a good way—the kind of laugh that tells you someone thinks you're stupid—and then walked out to "take care of something."

He made up his mind before they got to the technical section, which annoyed me at the time because the rest of the interview went well. Glad I didn't end up working there anyway, especially not with/for that kind of person.

Just some takeaways from your technical pieces though, if you'd like to hear them:

the guy asked me how I would mount an NFS share to a linux server and I said I would put an entry in the /etc/fstab file

I'd accept that answer, but I would probe to ensure you know the difference between mounting and persisting a mount across reboots. However...

But he was asking how I would theoretically map it to a web application.

I would answer that with, "I wouldn't. Unless there's some core architectural need for the application to share real-time file changes across the webserver fleet, I'd build an immutable artifact and deploy that instead."

Then you'd talk about that. Maybe it's a docker container, a zip file, a git checkout... who knows. When there's scripting languages involved, half the process is made up anyhow—you should see some of the InitContainers I've got. The important bit is why not NFS, and not necessarily why X instead. This kind of detail shows that you know the sysadmin stuff, but that you know the infrastructure behind delivering web applications too, which is more than just Linux" most of the time.

they asked me for 50 minutes about how I would set a fictional web stack environments and wouldn't move on... And I would ask for specifics and apparently that wasn't what he wanted. He would ask these highly dependent questions and asling for details got me more open endedness.

He ought to have a particular application in his head that he understands well when asking this question. However, you can make the rules instead in a way that lets you showcase your knowledge: use something you know. I'd fabricate a PHP app with various types of DBs and caching layers because I could speak to it easily from experience, then explain each of the decisions.

They said they wanted someone familiar with ansible and python and Linux but it all felt like that was second to what they really wanted. They didn't ask me about idempotency, or what linux commands would you use for x, anything python, and nothing about the stack they mentioned in their post.

This kind of stuff often is second to what a company really wants. They want someone with full-stack understanding that owns the infra. And the uptime. And the on-call rotation (lol). And performance. And deployments. And probably also the database...

I definitely got some terminology, reasoning, and examples in there to show them that I have infrastructure and Python experience, but it just got blown past while they beat a dead horse for 50 minutes...

"Infrastructure" is a loose term. At the end of the day, it encompasses the entire stack, even if it doesn't mean "the entire stack." These folks may just have a different definition than you do ¯\_(ツ)_/¯

Basically yes to all of that. I never actually used it but lab demoed it for the team that implemented VMware at the last job I used it at.

But I agree with the ethos. I would consider HA to be any type of self-correcting setup that guarantees a specific SLA, including replicas if the SLA calls for it.

And some HA implementations like AWS RDS do both. They run a second, hot server, but the switchover SLA is 30 seconds or something. You will miss a request even though it's marketed and referred to as HA. ¯\_(ツ)_/¯

You have to pick one, HA or single replica. If HA is a requirement, you need two replicas at a bare minimum (along with topology spread), that's a hard requirement.

That's kind of OP's point though. What you're calling a "hard requirement" is a limitation of the tech that the platform could work around if it was a little smarter.

Idk if you ever worked with vmWare, but their definition of "HA" was closer to what the OP wants—a VM that was configured for "HA" would be immediately restarted on another node if the server it was running on failed.

The point is that the definition of HA doesn't have to imply an architectural requirement, but instead a reliability one. If you can start a new container in 100ms and your SLA is responding to HTTP requests within 1000ms, it's reasonable to assert that it's possible to meet five 9s (or whatever) with a single-replica workload.

To be unambiguous though, I would just run two replicas, because I want dev/test to mirror prod, and I wouldn't run something like this for prod.

I watched this then said to myself, "This looks like something o-mores would... Oh."

Looking forward to the youtube post :)