emails

\sigh

I’m at the age where shit just needs to work. Some sort of remote desktop, or NAS or a combo might be the better easier route.

I get that. I don’t built machines anymore - time sink - and I don’t rebuild my kernel, etc.

But the synch you’re thinking quickly puts you into a tier higher than you may have time for. And a NAS gets you most of the way there as long as you understand and accept a failed NAS (or its OS, or a non-redundant disk setup) is going to hose your work everywhere instead of just on the one discrete machine you were using previously. You’re trading one risk for another, and that may be a big deal.

Re-examine your goals, and be really sure to separate what needs to synch vs what doesn’t (hint: user data synchs, most OS setup does not) and then see if you can carve out a decent solution with that. Maybe it’s as simple as an eBayed refurb NAS and another offsite for backup.

Yeah. And the full root disk clone thing is honestly gonna be more trouble than value. Ensure the big-bang stuff is the same - packages, but even not perfect (as above) but just same-version where installed; and general settings - and then synch the homedir.

God help me, I’m thinking gluster between 2-3 machines, running a VM off that (big files so lock negot isn’t an issue) and having it commandeer the local vid for gaming. It’s doomed but it’ll be fun ha ha learning ha ha.

There are exciting ways to ensure some settings and configs are kept the same, too, when they’re outside that synched home space. Ansible if you like thunky 2002 tech, chef or salt for newer but overkill, or mgmtconfig if you want modern decentralized peer-to-peer reactive config management.

Jira, which is available as on-prem version.

Check again.

Either way, I’d consider moving off Jira.

Ha! My deepest experience with postgres was watching it fall over and wedge daily when run behind red hat’s satellite (the flailing lame foreman one, not spacewalk).

Wow, was it ever a dog. Yeah, I get it: the company who shat Systemd on the planet can’t be asked to do much better, but still.

Who says NAS to mean anything other than Network-Attached Storage?!?

“When I say left, I kinda mean right half the time almost.”

The wd60efrx is a 5400 with 0.00% failure. I think all the WD reds were 5400.

Iso27002 fail.

• docker kills validation, so we can’t assure consistency as we’re essentially dividing by plaid.
• npm can’t be run in prod due to inconsistency of upstream, and dev tools which are verboten in stage/prod.

an open-source social media scheduling tool.

Pshaw! Didn’t you read the tin? It’s the ultimate open source social media scheduling tool.

As an end-user (that is, the IT staff that will be deploying/managing things), I prefer less-frequent releases. I’d love to see 1 or 2 releases a year for all software

The hard floor for release frequency must always be “as security issues are fixed”, and those will rarely be infrequent in our current environment of ever-shifting dependencies.

If your environment is struggling to keep up with patching, you need to analyze that process and find out why it’s so arduous.

As an example, I took a shop from a completely manual patch slog 10 years ago to a 97% never-touch automated process. It was hard with approvals and routines, but the numbers backed me up. When I left 2 years ago, the humans had little to do beyond validation.

The sad news is, the great loss of mentors after Y2K will be seen again after RTO, and we’re not going to fix the fundamental problems that enable longer release cycles in a safe way; and so shorter update cadence will be our reality if we want to stay safe …

… and stay bleeding-edge. Shifting from feature-driven releases to only bugfix-driven releases means no churn for features, but that’s a different kind of rebasing. It’s the third leg of the shine-safe-slack pyramid; choose 2.

Don’t forget, disaster recovery with a 7010 is a bobble, as you pull the disks out of one and pop them into the next and you’re likely back up and running.

Or, hell, run two with gluster. ;-)

Pros:

• better validation of installation and content, as long as you’re otherwise set for that.
• easier setup
• easier management
• easier teardown
• simpler firewalling

Cons: (vs docker-on-vm)

• your homelab isn’t someone’s resume

support us at https://buy.immich.app/

Blank page. JavaScript crutches?

Zero.

I run VMs and LDoms at work and VMs at home, a dwindling number of VMware VMs and a growing number of qemus to replace them.

I don’t need the hassle.

A easy to use DIY grow controller firmware (for cannabis).

It would be “an [easy-to-use D.I.Y. growth] controller firmware”, but ‘firmware’ isn’t a countable so doesn’t need that article.

It’s neat how that’s two mistakes in one letter.

docker

Welp, I’m out.

Mine are the ones that properly report their software versions to hrSWInstalledTable.

Thanks for putting the hyphen in the title.

It’s okay to still use a hyphen between ‘load’ and ‘balancing’. As a bonus, what you write would then be English, too.