To keep with the analogy, isn't that sort of like testing two cars by having them both drive the same few hundred foot stretch of new road at the posted speed limit of 35 MPH? You will test some things doing that, but not particularly well, and hardly all the things people find interesting and useful for comparing the performance of cars.

To bring ng this back to the discussion at hand (and to be redundant, as it's been mentioned here already), there are many aspects of using an LLM that are not purely about the output from a single or few well formed prompts. Additionally, if the end results are very similar, these othrr aspects will have an outsized influence on people's perspective of the tools, as they're the only differences worth choosing one model over another.

We don't, since we're not implementing a UI from scratch, we're matching something else.

Of the two possible worlds where in one this reimplementation matches what some see as annoyances in the interface or in another they mostly match the interface except for a few cases where the purposefully diverge (for no good technical reason), IMO the latter is far worse and causes more enexpected behavior.

At most, add a special flag to opt into different default behavior so nobody is surprised by running the same command on different systems and getting different behavior.

To be absolutely clear, since on reading this later it may come across as me masquerading as part of the OpenBSD project, I am not affiliated with them. My "We don't" was in response to "If we have a chance to change rsync defaults" which we, as the general public and users (and very likely also any reimplementors) don't have that chance, because rsync has a solid UI that people and tools have integrated for over a decade, and that's not something you can just change.

you responded to a comment that states "we should", your comment is a clear response to that. at least i understood it as intended.

Even if this law just caused companies to put into their sales contracts that they will support the servers to a certain date X years in the future and then handling of the online services would pass to a third party that might charge a nominal fee to administer the service, that would be an enormous win for the free market (in that it makes obvious what was ambiguous about a good) and for people both better knowing how a good will function in the future and what future costs there might be. In a way, this could just force companies to provide the equivalent of a warranty for the functioning of the online aspects of the software.

People far too often forget the absolutely vital aspect information plays in the free market, and anything that increases information (for example, how long a good should be expected to continue to function) is a net good, when compared to a complete lack of information about that.

> Just releasing code to users would be a pretty serious abrogation of creditor rights.

Would it, if legally required at the point of sale of the good the source code is based on and utilizes? I doubt creditors claiming ignorance of state law works well as a defense.

If they did that, people would notice, it would be talked about, and it would be factored into (some) people's decisions on whether the game was worth the price. That's the market figuring out how to appropriately price a good based on information about it, which I think would be good. Even if that's the only thing this legislation changes I think it would be a good change, by forcing what was an ambiguous aspect of the good you purchased into a well understood and legally enforced aspect.

Of which year? GTA6 has been in development so long they could miss that period slightly in a year and decide to wait for the next year and polish it up and they likely wouldn't run out of things to fix or make better.

> So, the company makes the promise "we'll have ready by November". They make this promise in April.

Make smaller promises but make them more often, and shit changes more often. Be clear about features 3-6 releases out, and when and why features get bumped. Companies delivering software are already doing this because they often can't deliver in 6 months and telling the customer it will be in the nest release a year from now does, as you note, make them stop doing business with you, so instead now you can tell them it's just delayed by a few months which they can maybe deal with.

Games don't really work like this, but games also don't seem to really work the same way at all and have different incentives.

Definitely flying too close to Poe's law for some.

I think maybe how you are conceptualizing design and how the GP meant it are not in agreement, and if you came to agreement on what it meant you wouldn't really disagree about the point either.

For example, I think design, as they mean it, could be described as "how to get that thing we care about". The correct amount of design depends on how exacting the outcome and outputs needs to be across different dimensions (how fast, how accurate, how easy to interpret, how easy to utilize as an input for some other system). For generalized things where there's not exacting standards for that, AI works well. For systems with exacting standards along one or more of those aspects, the process of design allows for the needed control and accuracy as the person or people doing the work are in a constant feedback loop and can dial in to what's needed. If you give up control of the inside of that loop, you lose the fine grained control required for even knowing how far you are away from theoretical maximums for those aspects.

If you have a complaint against "scientists" as hsme homogenous group, I think I'm going to have to ask you to explain how these particular scientists did not do that, and why you would think this is a problem of scientists (a label for a largelt disparate group not connected through any specific communication or hierarchy and mostly in output) in general?