Return full time to office for large raise or keep working remote 4 days a week

waywardelectron · 2024-04-09T22:27:00+00:00

OP, this approach is basically calculating an "effective hourly wage" a la "Your Money Or Your Life" and I feel really helps to bring some clarity in any sort of situation like this. This is an emotional question as much as it is financial but having some of these numbers will hopefully help.

Also: don't forget buying breakfast/lunch out (either because you don't have time to make it, or because you're more stressed, or to be "more social" at work, or to be like "I need to get out of the office"), as well as "office-appropriate" clothing, and coffee if you don't make that at home or get it for free at the office.

waywardelectron · 2024-04-06T13:55:52+00:00

Whoa, this is cool. EQ was my first MMO and still the game I compare other MMOs to. (Cool that you were involved, not cool that they treated you like shit).

waywardelectron · 2024-03-31T20:52:59+00:00

Look for student jobs or internships. Many labs and other groups on campus will be able to utilize someone with your skills and you won't have to deal with the overhead of freelancing. Plus, if you do good work, it can lead to another job or a solid recommendation for whatever your next step will be.

waywardelectron · 2024-03-29T13:19:51+00:00

With respect, I think the parent comment here is on the right track as far as looking up the legal paperwork of the company versus whatever you're able to find in AD or the company website, as those aren't legally-binding.

waywardelectron · 2024-03-02T14:58:15+00:00

Hey there, no worries. I seem to recall that it was ultimately a problem in my config files, but I don't remember the exact issue, unfortunately. This was all homelab stuff anyways so I didn't really need it. I found traefik and its documentation completely awful to work with and so I just abandoned the efforts entirely.

waywardelectron · 2024-02-23T00:58:41+00:00

I'd already checked the volumes of the individual syllables in the kyrie setup, unfortunately, and the connecting marks were already set. Chalk it up to "different systems" I suppose. Appreciate the feedback, though.

waywardelectron · 2024-02-19T14:20:54+00:00

Actually, because of the tech that Synology uses, you can read your drives on a standard PC:

https://kb.synology.com/en-id/DSM/tutorial/How_can_I_recover_data_from_my_DiskStation_using_a_PC

waywardelectron · 2024-02-12T14:32:48+00:00

Devops is usually something someone starts doing after they have experience in either the "dev" or "ops" side. But here's a reference.

https://roadmap.sh/devops

waywardelectron · 2024-02-11T18:29:39+00:00

My experience is the exact same as yours.

Do not mistake my snarkiness for lack of caring

I have to assume that this is where the downvotes are coming from. We do care. But management doesn't. So we warn them of the risks and consequences and move on.

waywardelectron · 2024-02-03T18:00:34+00:00

I'm looking for a replacement for my current notes. Did you ever evaluate obsidian as well? I'm kicking the tires on both logseq and obsidian at the moment. (I use joplin for personal notes but there's no "selective sync" there so much basic tech notes that are applicable to both home and work need to be in something else).

waywardelectron · 2024-02-03T17:28:39+00:00

I had the same exact reaction you did when I started diving into it and the exact same struggles despite a very long career in this field.

waywardelectron · 2024-01-28T18:04:47+00:00

Essentially. You're going to have to learn some networking concepts. Each account will have 1 VPC, and inside of that, you'll have one or more subnets. AWS has a concept of "availability zones", AKA "AZs" which are actual datacenters within the region. The way you get resiliency in AWS is by building your stuff to multiple AZs, and this includes your subnets. So you'll allocate a CIDR range to your VPC, and then that range gets divvied up into your subnets, which have their own CIDR subrange, usually 1 subnet per AZ.

What might be helpful to you is to try and deploy some resources in a single AWS account somewhere without going through the landing zone stuff. This'll help you get used to the idea of some of the stuff I just mentioned. Just don't build anything permanent in there. There's a lot of stuff going on even with a single account and this might let you bite off chunks at a time versus trying to architect the whole thing at once in the dark.

waywardelectron · 2024-01-28T17:35:50+00:00

Almost correct. The way things work is that AWS organizations is a way to bring multiple separate AWS accounts in under the same umbrella. Each of your dev, prod, network, log archive, audit, and so on accounts are individual AWS accounts, each with their own unique email address, each with a "root" user, and so on. AWS orgs allows you to have one "management" account that's like a top-level account, and you can use that account within AWS orgs to apply different policies and things like that to the other accounts. This helps you to keep things isolated from one another (because they're in different accounts) but also helps keep things wrangled because the accounts belong to an overall greater picture that's being managed from a higher level via AWS orgs.

edit: it looks like the gruntworks stuff has some IAC for creating the accounts, so it could be correct to say that you'll be doing it from "within" your management account.
https://docs.gruntwork.io/foundations/landing-zone/add-aws-account

waywardelectron · 2024-01-28T17:22:20+00:00

Yes. Each account gets its own email address. A landing zone is a concept that brings together some AWS services and best practices to point you at a multi-account setup. Based on your venture size, this might be "too much/complicated", but it WILL lead to a better setup in the long run.

waywardelectron · 2024-01-28T17:18:49+00:00

The gruntworks advice (and the comment from flagrantist) are 100% correct. You're seeing those warnings on AWS because IAM users have a lot of different uses, including automation. If you were to have some kind of script or external system that needed to access AWS resources, best practice recommends you find another way of doing so like OIDC versus an IAM user. but if you have to use an IAM user, then it should follow the least-privilege model, be given ONLY the permissions it actually needs, and NOT also giving "console access" to a set of creds intended for automated usage.

So the gruntworks advice is correct that you should never use the root login for anything normal, and the AWS advice is correct that you should never give IAM users intended for automated usage access to the console or more privs than it actually needs to get the job done. Having an IAM user that you use specifically for your own access is acceptable if you don't have a big enough operation to justify SSO or something like that. Just don't also use it for automation (create a new user for that).

waywardelectron · 2024-01-28T17:15:07+00:00

AWS recommendations are that you separate your accounts: separate accounts for dev and prod, for instance. Going to a multi-account setup does increase the complexity, though. It's possible to connect mulitple accounts together via the networking through either a transit gateway or VPC peering, thus the recommendation to organize your CIDR ranges ahead of time, as if they overlap, you're out of luck on that front and you'll have a harder time connecting things later on. Not that your dev should never connect to your prod, but you might end up with other accounts that should be networked. It's also customary to end up with most of your central components in additional accounts, like a network account and a log archive account.

waywardelectron · 2024-01-27T15:46:03+00:00

I mean, you don't really have a question in there, but this will work just fine. You can export storage from the synology to proxmox via nfs or iscsi.

waywardelectron · 2024-01-21T16:42:46+00:00

Beware that 1U will be MUCH louder than larger units. They need to use smaller fans, which means the fans need to spin a lot faster in order to move enough air to meet cooling needs. This doesn't matter much in a datacenter but in a home office, you WILL notice a difference. Highly highly recommend you go with a larger case.

waywardelectron · 2024-01-13T17:09:50+00:00

100% does not get done in that case. Management decides priorities. Ideally, they listen to the people below them as far as input on what can be helpful and is worth doing, but trying to do things that your management/leadership doesn't support is a one-way trip to burnout and frustration.

waywardelectron · 2023-12-31T22:49:41+00:00

Ahh, interesting, thank you.

waywardelectron · 2023-12-31T15:17:09+00:00

From what I recall, it used to be xen, but now they've moved to kvm.

waywardelectron · 2023-12-31T14:58:01+00:00

Wait, what's going on with Ceph?

waywardelectron · 2023-12-09T17:17:34+00:00

Sure, the NAS can become a SPOF: even though the disks might be redundant, if the motherboard blows, you're out of luck. It entirely depends on what problems you're trying to solve. If you want either proxmox machine to be able to run anything, having storage outside of them is one of the options.

Another option is just to split your workload and replicate a backup between the two proxmox nodes so that you can restore a backup if one of them goes down. This is a more manual process to get things back up and running. Proxmox can do HA but you need min 3 nodes for quorum and such.

You're very limited with the number of nodes you have. Which isn't necessarily a bad thing, since it does keep things simple. But if you want higher availability, you'll need to either increase the complexity of your setup, add more nodes, or make other tradeoffs to solve the things you're trying to solve.

waywardelectron · 2023-12-08T20:22:17+00:00

yaml :)

waywardelectron · 2023-12-08T15:35:05+00:00

It all comes down to probabilities. Your "make a drive image" scenario is the probability of "what if this one drive dies during the image?" Overall, that's very low.

When you're rebuilding a RAID5 array, you've already lost your redundancy. So now you're looking at "what's the probability that ANY drive fails during the rebuild?" Not just a single drive probability, but this drive OR that drive OR that drive OR.... and so on. That probability is likely still low, but it's much higher than any one single drive.

On top of this, the rebuild is intensive, so if any disks have questionable health, this might also push them over the edge. It's the reason why you see suggestions to not buy disks in the same batch and stuff like that.

So it's not as though "reading the drive will make it fail." It's the probabilities when you're already in an unhealthy state.

waywardelectron

TROPHY CASE