On Mon, Feb 15, 2021 at 12:21:11PM -0500, Judah Kocher wrote:
> Hello Theo,
> 
> I never for a moment intended to convey that anyone "owed" me support of any
> kind for my outside-the-box use of this tool.

You couldn't be bothered to even send a dmesg or a copy of the script
with the first email. OK, say you forgot. I do sometimes. Where was your
immediate reply with those missing and always required items?

>While I don't understand your
> vitriolic response to someone else's application of your software for their
> own personal use in a way you do not condone, you are certainly entitled to
> be as outraged as you please.

Read the tech@ archives. Such a simple script is constantly being
criticized, give it new features, etc.......
This script was a gift. I ran systems for years without it. Don't like
the default script? Open it up and modify to meet your special needs.
Don't know how to write the code? Learn it.
If you don't understand what this script does, you REALLY need to learn
more about installs and upgrades.

> I remain grateful for the work you and others
> put into the OpenBSD operating system. It has been made clear on multiple
> occasions that use of sysupgrade with anything other than default responses
> is heretical and cancel-culture worthy

You appreciate the work, but you already know the default responses?
Then you are being rude. 

> but I don't mind breaking things
> while experimenting and do not blame anyone else when this happens, nor do I
> particularly care if anyone else is bothered by it as long as no actual harm
> is being done.

This is part of learning and a good attitude.

> 
> If anyone cares to read my original query from an intellectually honest
> perspective I think they would be hard pressed to respond as you have. I
> never claimed my "sysupgrade use was completely normal" nor did I blame the
> sysupgrade tool for the issue I am attempting to diagnose. I did not mention
> my usage of it because logically it does not seem to be relevant and I was
> concerned it would become an excuse for people to fly off the handle. I only
> had and still only have one question.
> 
> Does sysupgrade leave any kind of logging behind which could help me to
> pinpoint why it is failing on one system while working on another apparently
> identical system?

Read the script before posting the questions about logging.

> 
> If the answer is no, that's easy enough to say. If the answer is yes, that's
> also easy enough if anyone is willing to share where those logs would be
> found. If the answer is, "Maybe, but no one owes you that information" that
> is also perfectly true while kind of pointless to even bother saying,
> although a world where people only offer help to others when there is a
> financial obligation would be a dismal place indeed.
> 

Much of the world is indeed a dismal place. It's part of human nature.

> I did not and do not expect anyone else to solve my problem for me. If you
> have reason to believe that my "mis-"usage of sysupgrade has anything at all
> to do with this issue, I'd be curious to know how you would explain it
> working on 4 out of 6 systems. Since it seems unlikely that the exact same
> tool would work two different ways on two identical systems then logically I
> would assume that some subtle difference exists between them and was hopeful
> that any records of the sysupgrade process would help me identify that
> difference. I have been using this script on these and other less similar
> systems ever since the sysupgrade tool was released with no issues, and
> therefore I think it's reasonable to to conclude that using it this way,
> while not officially sanctioned, has nothing to do with what's going on in
> this particular case.

I really find your method puzzling. I ran into financial troubles and
had to drop a server running -current. So I added a second hard drive to
boot onto in case a new snapshot broke the system on the server running
-current.

I also do not understand while you are running -current and automating
installation on 6 systems. Does your script verify functionality on the
first system before moving on to the others? Are you caching both the
snapshot and package files on the first server? Then using those files
only to update the other 5 systems.
If not, then you are pretty much guaranteeing at some point that you
will have 6 different systems running different snapshots and packages.
That seems like a bad idea.
If all 6 systems go down, how will you fix that mess?

Please, please, please, format your messages to be readable!
Use some newlines.

Please leave the politically correct responses for elsewhere.
Read the different lists. Everyone gets told on or off list when they do
something stupid. Learn from it. When you know a helpful answer to
someone's question, answer it. Port something. Submit a diff, even if
it's a bad one.

Chris Bennett

> 
> Thank you again for your work on OpenBSD, including sysupgrade.
> 
> To everyone else on the mailing list, I do not apologize for asking a
> question but I do apologize for the drama it provoked.
> 
> Judah
> 
> 
> On 2/14/21 6:44 PM, Theo de Raadt wrote:
> > You are outside the box, by changing tons of stuff.
> > 
> > People who operate inside the box won't be able to help you.
> > 
> > And it is even less likely when you are dishonest in the original email.
> > You claimed your sysupgrade use was completely normal, but it isn't.
> > 
> > It is far from normal.
> > 
> > When we get reports like this where people "touch the insides",     both
> > Florian and I regret that sysupgrade ever arrived in the system.
> > 
> > We want to delete sysupgrade.  Or, every month or so change the internals
> > so that it will delete some people's machines.
> > 
> > Does sysupgrade recommend what you do?  No.  But you do it.  Do you 
> > understand
> > the concept of "you own all the pieces"?
> 

Reply via email to