u/khobbits

'Awe' means (or used to mean) something closer to "respectful terror".

When you look up at the sky during a thunderstorm, it's pretty but could just as equally kill you or burn your town.

The deity that has the power to decide to click his fingers and make you disappear or send you to Hell.

Like the feeling you get, sitting at a court room, looking up at a judge while he's deciding if you're innocent or going to go to prison.

The recent trend to make 'awe' closer to "amazement", is a bit more modern. I suspect this came from people trying to 'soften' the description of God in the old testament. Trying to describe to kids what 'awe' means.

I was certainly of the Toonami generation, and grew up with things like Dragonball, Pokemon, Sailor Moon, Yugioh, and Beyblade.

I recall convincing my mother to take me to see the first Pokemon Movie in the local cinema, in fact I think that was the first movie I'd even seen in a cinema.

I owned both Yugioh cards, and a Beyblade. Both picked up at Highstreet stores.

To me as a child though, that wasn't really 'Anime', it was just a cartoon on 'cable'.

I think sometime later in my life, years after I stopped watching cartoon network, I was reintroduced to it.

During college, I remember watching rss feeds, or sitting on IRC channels, waiting to see the notification that the latest episode had dropped. With fansubs racing to be the first to get a sub uploaded.

As far as official releases, or DVDs, sure, they existed of a few select things. If you go to the biggest DVD store in the city, you might find the first season of Bleach in stock, but nothing later. You might be lucky if there was a single shelf in the whole store. And most of the time, it would take years for something to be dubbed, and make it's way over.

If it wasn't for my Toonami exposure, I'm almost certain I'd never have given Anime a chance, but if it wasn't for my exposure to fansubs, I'd never have picked up a subscription to Crunchyroll.

The source of this probably comes from a misunderstanding, of what the 'friend visits' are typically.

A lot of the time this is friends that live very near each other, a short walk away.

It's normally expected that kids who live nearby, would be free to just walk out the house, walk down the street and knock on the neighbours door and ask to hang out. Literally on the fly, no plans etc.

In this sort of situation, you would be expected to go home to your own house for dinner, as your own parents will be cooking. The same as if you were playing sports in the street, or riding bikes/skateboards etc.

If a 'play date' is planned in advance, the agreement on who is cooking, would be part of that plan. This would be typically done, any time any sort of real transport would be required (Car, Bus, Train).

This was a somewhat common occurrence when I was in my teens. I used to often visit a friend the next street over, who had the house to the back of mine, so we shared a fence. They would typically eat early, and my family would eat a little later, after my father finished work.

So if I was visiting that friends house, say playing video games in their bedroom, the friends mother would shout up saying "Dinners ready", and my friend would go down to the family meal, and I'd continue playing the game.

45 mins later, my mother would shout, "Dinners ready" over the fence, and then I'd go get my own dinner, with the family.

Occasionally, if my father was working very late, I'd be asked if I wanted to eat at my friends house, rather than wait.

It's all just a matter of respect really. You don't ruin a child's appetite, without communicating with their parents first.

I think I've got a fairly good mix of Autism and ADHD.

I tend to work in systems automation, and infrastructure architecture, while working in a fast paced environment.

Basically, when it's quiet my job is to make sure things are as automated as possible, and things are as well architected as possible. This means, I often get to rebuild existing workflows to make things more consistent. That makes my autistic side very happy.

When I'm not working on automation/architecture, I'm thrown into 'bailout' or 'time critical' project. This is usually a "Could you swoop in and save project X" or "We need to do X in Y days, this is your only priority". This makes my ADHD side very happy.

I feel, and I could be mistaken, but my specific combination of Autism, and ADHD, cancels out some of the downsides of each.

I've never felt the need to to get diagnosed or medicated, as I feel like things work, and I do tend to get appreciation at work. My wife got her ADHD diagnoses a few years back, and is now medicating, so I'm familiar with the process. I'm more worried about messing with something that earns me a paycheque.

Nope, CGI, for things like adverts and movies.

As someone else said, it's probably for a sysadmin in charge of a datacentre. Not a bad job, if you live close enough. I did that for a bit, the only problem was I lived about 90 mins away. I got used to taking meetings while travelling.

Yeah, I was the lead sysadmin in the head office, for a fairly large company, that got bought out by an enterprise.

Before the buyout, I could wear all the hats. Networking, firewall, security, storage, virtualization...

In the morning I could be running cables between racks, after lunch sitting with the dev team to architect iam policies on s3 buckets, and in the afternoon doing mailbox searches as part of 'discovery'.

The next morning, I'll be writing puppet for selinux policies, upgrading redhat, on our LTO management server, and by afternoon planning ISP connectivity for a new office, or tweaking GPO policies.

After the buyout, half those things went away, but in came enterprise solutions...

I'd probably take that job.

I've done that previously for $100,000. Although it was 'Nutanix' not HyperV, and 'Juniper' not 'Cisco.

It is missing "Cloud" though, you can't forget about Cloud. You need to know how to manage everything from OKTA SSO, through to Terraform cloud deployments in Azure/AWS/GCP.

Note: I probably live somewhere with a lower cost of living than you do

In my last large enterprise, we were using Nutanix, which uses a lot of the same components as proxmox.

At my mid size business we're using proxmox directly, as Nutanix would be a bit above our price range.

I'm around that level.

In my last role, I was 'Lead Sysadmin' for <Business unit> Europe.

Each day was 20-50% meetings.

I had 2 direct reports, that I was responsible for doing reviews, salary negotiations etc.

I did have the option to let my manager do the managing, but at the time I thought it would be good to get some line manager experience.

I'm now at a company where I could probably call myself the 'Lead Sysadmin', for the whole company, with no direct reports. I'm doing pretty much the same job, just with less meetings, and without the management paperwork.

I find the opposite works better.

3rd row first, 2nd after, first row after that.

Means there is a little more time on that last wave, as there is less travel time.

Sometimes the waves go just a little out of sync, so if the final wave is sent with say 6 mins remaining, there is still plenty of travel time from wave 1 to bear.

Linux Sysadmin here who has managed mainly Linux estate companies for over 10 years.

I work in the VFX industry, we run a lot of VFX workstations, and render nodes.

The idea is when you're working on a big movie, say like the recent Disney Lion King, you want a wide fleet of machines running exactly the same software, in tightly controlled environments.

One data centre I helped manage last year was probably about 120 racks of servers, render nodes and workstations. If you added it all together, probably about 2 racks were Windows, half a rack of mac (mixture of trash cans and mac minis), and the rest were Linux.

There were a few business units located in there, so there were a few management solutions, but it was mostly Puppet and Salt, combined with Foreman for central management.

That said, it isn't as if there were no windows servers... I think we had about 100 windows VMs running on one of the VM machines. Mostly vendor specific stuff, related to things like finance and business analytics.

And Active Directory. We had a single source of user truth, was central to the whole business. We would sync AD with OKTA for SSO, Google workspace, Office 365, HR platforms, etc. AD was central to it all.

We would add users in AD to 'Linux enabled' (gid assigned) security groups, for things like 'can a user reboot a server', there would be a group 'sudo-workstation-reboot'. The config file on Linux would be managed by salt/puppet, and when the user tried to reboot, the machine would check to see if the user matched any rule in the sudoers config files.

As far as home directories... We would have a central SAN/NAS for the business unit, and the folder would be exported with both NFS and SMB. For people using windows, the GPO would mount their user folder to a 'U' drive, and for people using Linux, the folder would be mounted as '/users/<username>/.

Both Linux and windows would use the same 'desktop' and 'documents' folder, so you'd keep the same files.

Because we were operating under high security... Such as having the raw files for the next episode of GoT, or marvel movie, we wouldn't do any file sync outside of the datacenter.

Files were not allowed to leave the controlled production zone, unless it was your explicit job to move the files to and from the client.

For the regular user, working from home or office, they would use a remote desktop technology, like PCoIP, to connect from their laptop or thin client, into this high powered workstation, where they would work, within a few ms of the SAN.

I wouldn't want to remotely manage Linux laptops... I've never used a good Linux MDM. I don't have a solution for that. But policy, security, and fleet conformity, salt/puppet works wonders.

Seems like a legit strategy to me.

If an alliance is going to fall out over something lame like this, better to move them on. 

The experienced players on server know that come KvK all alliances on the server need to cooperate.

All players on the server are part of the same team, just have different families.

I'm not sure the DOD is a good benchmark for how fast the French goverment's adoption is going to be? They already have departments that are all Linux, and others that are already part of the way there.

A lot of internal apps started moved away from native apps, to webapps (albeit .net webapps) decades ago.

Yeah, it depends on interviewer. I typically find the 'specific' questions interviews are for more junior roles, like helpdesk. Although I guess it will depend on business size.

I prep a batch of probably something like 20 questions when I'm hosting an interview, covering things like "Give me an example of a time when..." and "If I asked you to do X, how would you..."

I prepare them with the intention to ask as few as possible. I try to keep the questions open enough, to allow a discussion. I intend them to be more conversation starters, then something I'm scoring on.

It will also depend on earlier questions, so if when I ask:
"How would you describe your experience with the cloud?" the person says "I barely used it", I might decide not ask a question like:
"We've been asked to lay the ground work for opening a new office in a new region. Corporate want to investigate using Brazil as a hub for staff working across south America, and have selected a wework for our first regional presence. How would you approach the problem?"

If the migration is done in stages, say keeping office 365 but dropping Windows, I think the migration would go a lot more smoothly than people think.
The web versions of office365 are pretty good, and are good enough for most people.

10-20 years ago, almost all governments would be custom written apps that only ran on windows, now I would bet that most government workers will be using web apps, and those that aren't migrated to webapps will already be planned for replacement.

This will likely turn into a mostly nothingburger for most people.

You can customize Linux to look a lot like windows, especially if 95% of what people want to do can be done in chrome.

It will almost certainly work out cheaper in the long run.
We're talking governments here as well.
This decision will pay off quickly.

I've not had that many interviews as I tend to get a bit comfy, and haven't job hopped as much as I probably should have, but the interviews that went well, tended to be me interviewing the company rather than the other way around.

Most interviews I've done, either as a candidate or employer, start off with an introduction about the company, the role, the team you'd be working with, and the infrastructure you'd be supporting.

I tend to not let the interview get past that stage. Either by asking direct questions, or trying to build enough of a conversation around those that we take up most of the allocated time.

This might go something like:

Interviewer: In this role you will be supporting both on prem and cloud infrastructure
Me: For the on prem, are we talking computers under desks, servers in a server room, co location?
Interviewer: We've got a colocation in east London, and most the hardware would be there....
Me: Is that Global Switch or Digital Realty in Docklands?
Interviewer: Ah yes, we're located in GS2
Me: Ah, yeah, is that going well? I had to do a datacentre migration from there to Slough in my last company because we judged it too expensive.

From what I've been told, it keeps the conversation on areas I choose, rather than the interviewer, takes the stress away from them (most people don't like to host interviews), and let's me show off my experience in the way I want to.

My most successful interview got bogged down in the describing of the cloud infrastructure part of the description for about 25 minutes, as I was asking infrastructure related questions:

Something like:

Interview: We're using AWS Elastic Beanstalk to host our web applications
Me: Are you finding that gives you the flexibility you need, or are you considering an migration to ECS or EKS?
Interviewer: It's one of the things we're considering, as we think it could allow us to save a bit by collocating applications.
ME: What is the current forerunner?
Interviewer: That's actually one project we were hoping you would be able take lead in...

I've not had much problem with Claude for sysadmin. I gave it something like "User complains workstation is slow", and gave it access to graylog and prometheus, and it was able to diagnose a bad optic within a lacp bond.

I've found it was able to generate me selinux rules based on log soak.

I've had it troubleshoot BGP routing between sites.

I did ask claude to write a 'troubleshooting' skill for itself, to tell it to stop throwing out complex hypotheticals, when suggesting a troubleshooting command would confirm it, and that helped narrow the message sprawl.

Hmm, I actually have no idea.

In the past, I've had basically a license server per 'os version', So our oldest one is running centos 4, license2 runs centos 5, license3 centos 6, etc.

Some of them have usb license keys stuck into usb docks, hanging out the back of the server.

The amount of licenses we had from companies that no longer exist....

If the software requires something special we'd install it, but most licenses just get slotted into RLM.

We tend not to have the idea of 'project' machines. Machines could work on 4 projects during the day, and then render on 60 projects overnight.

So I guess in most cases, the license goes on the rlm server, and get's used when needed?

As far as scoping a plugin... That's done as part of the environment building. Normally we'd try to fix specific versions of software and plugin sets into the project environment.

That's been done a number of ways, from 'jobbing in' (a specific script you'd run in the project directory before launching software), to overriding the 'cd' command to update the 'env', every time you change folder.

It really rarely seems to be so.

The first few minor versions of most major releases of software tend to be more unstable.

When you get to the point of wanting render pipelines of hundreds or thousands of machines and committing hundreds or thousands of artist hours, you want to avoid 'quirks'.

It's not as if there is no testing, and nobody checking. Someone will read every change log, and be looking at how workflows would need to adapt, start designing things.

As far as incremental updates, for the most part, we require the entire fleet to have fixed versions of 'everything important'. Workstations join the render farm when nobody is logged in, and all machines that can render, should run exactly the same library versions of all dependencies. If a frame is rendered, it should render exactly the same on a different machine, down to the checksum.

Mostly, we usually get stuck on fixed versions for certain software.

So right now, the pickiest software I've got is Autodesk Flame, which for the currently deployed version only supports up to Rocky 9.5.

Ideally, I want to share software with the entire fleet, so my 3D workstations, can be upgraded to run 9.10, but jumping to 10.x could cause issues.

I'm told the most recent version of Flame isn't worth upgrading to, and all of the pipeline changes required to adopt it, make upgrading unappealing. I've not looked into it closely, but I think the biggest issue is something with how the newer versions of Flame share project files with other Flames.

As for supporting both 9.x and 10.x with the same /software... Well we've done it before. Sometimes it means writing painful wrappers, to force certain libraries, other times it means building logic forks so that:

on EL6 use /software/google/chrome/100/chrome while
on EL7 use /software/google/chrome/151/chrome

I'd expect upgrading will look like this:

- We validate a new version of Flame, that runs on Rocky 10.x.
- We validate maya and most of our core pipeline runs on Rocky 10.x
- We build dev workstations of both, put in front of the pipeline team.
- Get some senior staff to validate things 'mostly work'.
- Arrange a upgrade window, and re-pxeboot most the fleet
- Deal with any fallout

For the most part workstations are 'disposable', some artists get attached to specific machines, if they've got very specific requirements, but a lot of staff are just assigned machines from a pool, so they could end up on different hardware every day. Rebuilding machines can be done in parallel, and takes less than 10 minutes.

Ah, I see.

Where I worked, we skipped Rocky 8, went from 7->9... Which is probably part of the problem.

The issue was we had so many applications, and we're talking probably several thousands of binaries installed on our central software server, and all the software that end users use, runs from there.

So if you want to launch chrome, you're launching /software/google/chrome/bin/chrome

That /software/google/chrome/bin/chrome, is probably a symlink or bash script that actually runs /software/google/chrome/151/google-chrome.sh or some such.

Deploying a new major version of the OS, means making sure all of the launchers work on the new OS, trying to not break any of the existing machines.

The result of this, is basically every server and workstation in the company, can run virtually every version of every software we've ever supported. This means we can open the project files of a project for a client 3 years ago, with the exact program and plugin set, and re-render the whole thing today, on a 1000 node render farm.

It's worth also noting that installing new software is very easy you do something like:
`rpm2cpio package.rpm | cpio -idmv`
in a temp directory, and then just copy it to /software/vendor/app/version
And drop a launcher script or symlink in PATH.

Within seconds, the artist can start using the new version.... Creating more technical debt to be fixed, next major OS upgrade...

I don't tend to mind Rocky.

I've spent most of my professional career supporting RHEL based workloads, starting with Amazon Linux, Centos, full fat RHEL, and currently Rocky.

Feels mostly like a normal progression. At some point in the past I moved my homelab from ubuntu server, to rhel, because it's more familiar.

We're running it natively. The ones we use the most are Autodesk Maya, Flame & Arnold...
Although we've also got stuff like license servers, flame assist, flare, backburner...