dandi8 @ dandi8 @fedia.io

Posts

0

Comments

102

Joined

1 yr. ago

You seem to think that "open source" is just about the license and that a project is open source if you're allowed to reverse engineer it.

You have a gross misunderstanding of what OSS is, which contradicts even the Wikipedia definition, and are unwilling to educate yourself about it.

You suggest that Mistral would need to lend us their GPUs to fit the widely accepted definition of OSS, which is untrue.

You're either not a software engineer, or you have an agenda.

Because of this, I will not be continuing this conversation with you, as at this point it is just a waste of my time.

You're, hopefully not on purpose, misunderstanding the argument.

You can download a binary of Adobe Photoshop and run it. That doesn't make it open source.

I cannot make Mistral Nemo from just the open-sourced tools, therefore Mistral Nemo is not open source.

But then it's the tools to make the AI that are open source, not the model itself.

I think that we can't have a useful discussion on this if we don't distinguish between the source code of the training framework and the "source code" of the model itself, which is the training data set. E.g, Mistral Nemo can't be considered open source, because there is no Mistral Nemo without the training data set.

It's like with your Doom example - the Doom engine is open source, but Doom itself isn't. Unfortunately, here the analogy falls apart a bit, because there is no logic in the art assets of doom, whereas there is plenty of logic in the dataset for Mistral - enough that the devs said they don't want to disclose it for fear of competition.

This data set logic - incredibly valuable and important for the behavior of the AI, as confirmed by the devs - is why the model is not open source, even though the training framework might be.

Edit:

Another aspect is the spirit of open-source. One of the benefits of OSS is you can study the source code to determine whether the software is in compliance with various regulations - you can audit that software.

How can we audit Mistral Nemo? How can we confirm that it doesn't utilize copyrighted material to provide its answers?

We'll have to agree to disagree on pretty much everything, then.

You're trying to change the definition of open source for AI models and your argument is that they're magic so different rules should apply.

No, they're not fundamentally different from other software. Not by that much.

The training data is the source of knowledge for the AI model. The tools to train the model are the compiler for that AI model. What makes an AI model different from another is both the source of knowledge and the compiler of that knowledge.

AFAIK, only one of those things is open source for Mistral - the compiler of knowledge.

You can make an argument that tools to make Mistral models are open source. You cannot make an argument that the model Mistral Nemo is open source, as what makes it specifically that model is the compiler and the training data used, and one of those is unavailable.

Therefore, I can agree on the social network analogy if we're talking about whether the tools to make Mistral models are open-source. I cannot agree if we're talking about the models themselves, which is what everyone's interested in when talking about AI.

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".

Fair point!

I'm hoping for a 4-day 6-hour work week in my lifetime, but it seems the world isn't ready for that quite yet, even though I'm 100% convinced productivity would not be impacted in any significant way, at least when it comes to software dev.

A part of it is horrible practices and a work culture which incentivizes them.

Who can be happy when the code doesn't work half the time, deployments are manual and happen after work hours, and devs are forced to be "on-call"?

Introduce Test-Driven Development, Domain-Driven Design, Continuous Deployment with Feature Flags, Mutation Testing and actual agile practices (as described in the Agile Manifesto, not the pathetic attempt to rebrand waterfall we have in most companies) to the project and see how happiness rises, along with the project's reliability and maintainability.

IMO the biggest problem in the industry is that most developers have never seen a project actually following best practices and middle management is invested in making sure it never happens.