dandi8

That's like saying the source code of a binary is a bunch of hexadecimal numbers. You can use a hex editor to look at the "source" of every binary but it's not human readable...

Yes, the model can be published without the dataset - that makes it, by definition, freeware (free to distribute). It can even be free for commercial use. That doesn't make it open source.

At best, the tools to generate a model may be open source, but, by definition, the model itself can never be considered open-source unless the training data and the tools are both open-source.

Gee, you sure put a lot of effort into supporting your argument in this comment.

https://en.m.wikipedia.org/wiki/Open-source_software

Open-source software (OSS) is computer software that is released under a license in which the copyright holder grants users the rights to use, study, change, and distribute the software and its source code to anyone and for any purpose.

From Mistral's FAQ:

We do not communicate on our training datasets. We keep proprietary some intermediary assets (code and resources) required to produce both the Open-Source models and the Optimized models. Among others, this involves the training logic for models, and the datasets used in training.

https://huggingface.co/mistralai/Mistral-7B-v0.1/discussions/8

Unfortunately we're unable to share details about the training and the datasets (extracted from the open Web) due to the highly competitive nature of the field.

The training data set is a vital part of the source code because without it, the rest of it is useless. The model is the compiled binary, the software itself.

If you can't share part of your source code due to the "highly competetive nature of the field" (or whatever other reason), your software is not open source.

I cannot lool at Mistral's source and see that, oh yes, it behaves this way because it was trained on this piece of data in particular - because I was not given accesa to this data.

I cannot build Mistral from scratch, because I was not given a vital piece of the recipe.

I cannot fork Mistral and create a competitor from it, because the devs specifically said they're not providing the source because they don't want me to.

You can keep claiming that releasing the binary makes it open source, but that's not going to make it correct.

Just because open source AI is not feasible at the moment is no reason to change the definition of open source.

Are the petabytes of training data included in the repo? No? Then how could it ever be called open source?

At best, some of the current AI can be called freeware.

If you're just including the trained AI itself, it's more like including a binary, rather than source.

You can't really modify Llama in a significant way, can you? You can't fork it and continue improving that fork.

I meant this:

The biggest one for me is that most of the games come out on PC eventually anyway, and will generally run at higher resolutions and frame rates.

Did you edit the comment? I could have sworn there was the word "issue" in there, originally.

~~Is it an issue, though?~~

Edit: The whole comment was just a misunderstanding.

I'm fairly sure the crouch jump is part of the Half-Life 1 tutorial level.

I just beat this level yesterday!

It becomes easy... Once you know what the tricks are supposed to be, which the game doesn't tell you at all.

For me, these were the tips I needed:

1. There's a dedicated button for burnout, which makes it super easy to do the 360
2. the slalom only counts if you do the pillars on one side of the garage BOTH WAYS
3. To do a backwards 180, drive backwards, then push one direction, then halfway through push the other direction.

Supposedly the PSX version also has a video in the options menu which shows you a dev completing the course, with button prompts on screen.

Oh, and there's a cheat code in-game to skip this level entirely.

I think that would depend on the skill of the developers and the resources they are given.

A lot of us are only ever taught to be code monkeys and those would probably not naturally gravitate towards true agile practices (which most, I would argue, have never actually seen in a real project).

Another problem is a lack of access to domain experts, which is also crucial.

However, my current project doesn't have any managers, or even business analysts, there's only the developers and the Product Owner. We have access to some domain experts and we work with them to build the right thing.

It's going great and the only problems we are facing are a lack of access to the right domain experts sometimes, as well as some mismanagement in the company around things we can't do ourselves (like the company Sonarqube not working and us not being allowed to host our own due to budget constraints).

In conclusion, I think part of the problem is educating software developers - what true agile is and what the industry best practices are (some mentioned in my previous comment). Then you give them full access to domain experts. Then you let them self-organize. Basically, make sure you have great devs, then follow the 12 Principles of the Agile Manifesto to the letter and you've got a recipe for success.

Otherwise, results may vary a bit, as I think many would tend to continue doing the Fake Agile they were taught and continue producing the poor quality, untested code they were taught to produce.

I'm really not overloaded, I have a very agile team and we usually don't take more than we can manage.

But saying you can always, with 100% certainty predict what blockers may arise in the whole next week is a kind of clairvoyance I'm not sure is possible. If it was, we wouldn't need daily standups in that second week.

And, once again, Kanban is a thing.

Please, let's just not use "all work being done" as a metric for time off.

I mean, that's true, but the point still stands - every first Friday of a sprint there is ALWAYS going to be work to be done.

And what if they're doing Kanban?

The point is, Fridays off shouldn't ever be dependent on "all work being done".