"The future is already here — it's just not very evenly distributed."
--William Gibson, SF Author
https://en.wikiquote.org/wiki/...

Credit for the quote = https://en.wikiquote.org/wiki/... -- last bullet point.

I recently found Winger = https://addons.mozilla.org/en-... and it has very much helped me manage my tabs better than others I've used before! Primarily because it works with windows and tabs together.

Agreed, I have an Atari 130XE (successor) sitting in the garage, but I would consider this because it hooks up to a modern TV; adding HDMI and bundling a USB controller is considerable!

Contrast this to buying a Raspberry Pi 4b or 5, adding https://retropie.org.uk/docs/A..., but not having to deal with configuration, piracy, and home IT; then this seems reasonable purchase!

I regularly use https://swappa.com/ to buy Google Pixel 4+ unlocked handsets (don't buy a carrier version, they lock the bootloader) which are carrier and bootloader unlocked. They work with https://lineageos.org/ and https://calyxos.org/ and my phone works with Verizon and Visible in the US. So far, I've had one Android app not work on it, so that's 99% success using it as a smartphone for everything over the past year.

Learn how to back up your phone; the only problem with second hand devices is not knowing when the battery will misbehave.

Nope: http://principles-wiki.net/non...

It sounds like you have many ingredients of DevOps in your experience, but none of the benefits because they seem to be a drag on your efficiency. You may be in the middle of a journey that you've yet to realize how to raise the state of the art in your own work, your team, and your software development organization.

My definition of DevOps is: DevOps is the process of removing all friction between the developer and customer value.

You need to treat friction as technical debt: file a bug and work on it!

I think you are close, but I have to disagree with a point you make. You want SAs in the loop to **develop** the environments and tuning: we want infrastructure as code where sysadmins document their wisdom and make it reproducible everywhere (in dev, staging, test, etc.): not by hand in only in production. Otherwise, we end up with deltas between development and production, which is a gap that can cause trouble and problems to creep up only in production.

This is where we start to close the loop on infrastructure and software engineering by instrumenting our code with metrics, performing forensic analysis with logs, and tracking health/uptime/performance with monitors. Otherwise, yes - handing off production to the system administrators to do their dark magick is the old way and it is NOT the DevOps way.

DevOps allows us to approach the problem where tuning and troubleshooting on your laptop or in production should be, as much as possible, a shared exercise with shared tools.

There is so much misunderstanding because there is not a universal, static definition of DevOps that everyone can point to and say "that is DevOps" or "you are doing it wrong!" This is because DevOps is ultimately defined by the capacity of the people who practice it and I think we can see (already in these postings) that many people do not have the capacity to define it.

The history of DevOps begins with the people who coined it: Patrick Debois and Andrew Clay Shafer's first discussion about Agile Engineering at a conference in 2008, which led to a Google group and then to the first community meeting as DevOpsDays Belgium in 2009. W#e can trace to the beginnings and primary source folks, so please stop demonizing and making DevOps anything more mysterious than a knowledge gap.

For an overview with my definition of DevOps, please see my blog post with talk and slides that I presented at Silicon Valley Code Camp earlier this month:
http://mlavi.github.io/post/de...

You want infrastructure as code: when you shell into a machine, you've already lost the battle because you are going to be doing things by hand which is slow and fraught with human error.

Your general approach is correct: scrap the servers + packages, instead code them into a provisioning system such as Chef, Puppet, Ansible, Salt, etc. and handle all of the variables and corner cases for a fleet of servers with different OSs using these systems.

Model them for local development using Vagrant and eventually Docker.

Disk cloning is one easy way to solve this problem, but then you must customize the new clone, and that represents a different set of problems.
Eventually you learn that you don't want to copy the docroots or other data between each clone. In fact, your application or data or configuration up to date at the time of the snapshot, but may not represent the current application data or configuration.

This leads many to synthesize infrastructure via provisioning tools like Salt/Puppet/Chef/etc. following infrastructure as code principle and then to publish the application onto the server from revision control or even better, from a build system, because that is up to date.

The problem is that doing anything by hand is slow and introduces human error.

We all start to solve this by documenting your work procedures (i.e. a run book) to make our knowledge reproducible the next time we set up a server. The next solution is to code those procedures in a shell script to speed up things. However, you quickly find out that you'll need variables and you want to address corner cases because you need the script to work on more than one server. So your shell script needs to be tested in multiple places and you've now begun to code infrastructure.

Today there are many provisioning tools (and run book modules provided by the community) which solve this problem elegantly and allow you to provision a fleet: Chef, Puppet, Ansible, Salt, and many others. They allow you to scale your efforts so that you'll never need a full day to provision a server again.

We don't do things by hand anymore today: it does not scale and it is not repeatable.

Vagrant changed my life! Learn about Vagrant, use shell and evolve towards Chef/Puppet provisioning, then optimize toward application containers to go even faster. You'll gain the benefit of keeping your customer development environment on your Windows/Mac/Linux desktop or laptop while being able to test multiple different projects for different business clients reflecting their production environment.

I had a lengthier example, but I lost the post. Anyhow, this is the beginning of your journey to immutable infrastructure as code: a lot of buzzwords that won't mean anything until you complete the journey..

Vagrant is part of a free toolset ecosystem (Packer, Terraform, Consul, etc.) which solve modern infrastructure issues that the OP is expressing: the Vagrant creators are smart and approachable in the forums and I've had the chance to meet some in person to confirm they are humble and generous souls.

Check out Pertino.com, a network as a service startup. You can set up a free account for three devices forever. If you need to expand past three devices at the same time, then Pertino has become valuable to you.

At a minimum, you get a very easy to use (and administer) private, secure network between you and whomever you invite onto your network, so you can do Remote Desktop, VNC, X, or whatever else you choose for you and your family to use without resorting to GotoMyPC, WebEx, etc. (mind you, all of those solutions are valid Desktop Sharing services, too) . But you can also do NFS, SMB, FTP, etc. for file sharing. Or anything: you finally have a virtual private network where you and your remote clients/family get a LAN-like experience in the cloud.

Full disclosure: I work there, so I am hopelessly biased. The value I see in this solution is that it is easy and secure for everyone, covers mobile and desktop, and allows you to try almost any solution out there to solve your needs because you have a peer to peer network with remote devices.