My main interest is my startup. So, what I really care about is my development system and, then, my production system. Since the development seems nearly done and is in alpha test, soon I will be highly interested in my production system.
One of my concerns is a standard, old one: On a system used for development or production, don't change any of the tools until are ready to accept the extra work of fixing any new problems the changes cause.
So, just delay changes to fit my work schedule. E.g., I don't want some change, intended to be good, break something in my tools or my production software. Such things have been known to happen; I haven't seen such in Windows, but at one point I was around some high end production systems where one hour of outage in a year meant that the CIO lost his bonus and two hours, his job. No joke. Walk around the raised floor? Not a chance! They were uptight. A change or update? Fine: Run it on the side for no less than six months. Well, the fundamentals of that situation have not changed.
Really, soon into production, I will want a test system on the side, put any changes on that system first, run it with the best test workload I can, and after some weeks usually implement the changes on the production systems.
On Windows, I've gotten good at using the old NTBACKUP to backup a copy of a boot partition and, later restore it. I have several such backups for my current, main boot partition.
When I get closer to production, if some automatic updates were applied to a production boot partition, I might save the partition but I definitely would restore back to the version before the updates.
My main interest is not as a consumer user but as a developer of a startup that could become serious, maybe an average of an hour a week of 75% of the people with access to the Internet -- IMHO my software has by a wide margin the best solution for a problem serious for nearly every user of the Internet. That's my main interest.
One of my concerns is a standard, old one: On a system used for development or production, don't change any of the tools until are ready to accept the extra work of fixing any new problems the changes cause.
So, just delay changes to fit my work schedule. E.g., I don't want some change, intended to be good, break something in my tools or my production software. Such things have been known to happen; I haven't seen such in Windows, but at one point I was around some high end production systems where one hour of outage in a year meant that the CIO lost his bonus and two hours, his job. No joke. Walk around the raised floor? Not a chance! They were uptight. A change or update? Fine: Run it on the side for no less than six months. Well, the fundamentals of that situation have not changed.
Really, soon into production, I will want a test system on the side, put any changes on that system first, run it with the best test workload I can, and after some weeks usually implement the changes on the production systems.
On Windows, I've gotten good at using the old NTBACKUP to backup a copy of a boot partition and, later restore it. I have several such backups for my current, main boot partition.
When I get closer to production, if some automatic updates were applied to a production boot partition, I might save the partition but I definitely would restore back to the version before the updates.
My main interest is not as a consumer user but as a developer of a startup that could become serious, maybe an average of an hour a week of 75% of the people with access to the Internet -- IMHO my software has by a wide margin the best solution for a problem serious for nearly every user of the Internet. That's my main interest.