Why would they have to be killer robots strapped with explosives? If we have highly capable semi-autonomous robots they could be non-lethal with no risk of life to their owners.
It upends the entire paradigm of kill-or-be-killed warfare.
Rather than blowing up a school full of little girls, you could deploy a swarm of thousands of fast-moving cat-sized robots armed with tasers and bolas to identify and capture targeted enemy leaders.
I did this with some proprietary hardware. It's an HDMI encoder lor the original Xbox. I designed a PCB to be electrically compatible along with being compatible with running a binary provided by the original maker. I used the same microcontroller so it could be flashed using his binaries that I was able to extract from an app he distributes. Normally, you'd run the updater app on the Xbox which sends a firmware update over the SMBus to the microcontroller but it's easy to slice up the updater app to extract the firmware image. Then you can use an ST programmer to flash the image to my clone. Despite what it says on my GitHub, I did actually get it working but there's some irregularities between original Xbox revisions that make my design not universal. Oh well, at least it works for me and I didn't have to give this guy any of my money.
The whole project started because this guy changed the design of his HDMI encoder to move the microcontroller off the board and into another board he sells that provides an alternative BIOS for the Xbox. Meaning instead of paying $60 for one board, you now pay $50 for the neutered board plus $100 for his other board. Someone released a barebones board that had the same microcontroller (running his firmware) on it that could be connected to this neutered board and this guy sent a DMCA takedown notice to a site hosting the instructions on how to build it. A lot of people in the original Xbox modding community got upset so some people were looking for ways to build open source HDMI encoders as a means to kick the proprietary junk from the community. I took it a step further and just built a clone.
That's how I feel about clones in general. Ok, I owned a real Commodore 64, but all my PCs during my formative years were clones.
Actually, this wasn't such a good example since I believe PC clones were legal. Let me change it to something more controversial:
I feel the same way about software piracy. All my games and software growing up were pirated. I didn't even understand this, because you got software by going to a store and buying it, e.g. C64 games... but it was all warez. Same with DOS or Windows (which one usually got from someone else). All of my early programming languages were pirated too: QuickBasic, GW Basic, Turbo C, Turbo Pascal, etc.
And this is how people got acquainted with computers, and then got into programming (games, systems, business software) as a job. So piracy was a net win.
I do recall the assistant at the store when I first showed up said wait for the upcoming Commodore 64 more stuff for much less money. But as a 14 year old I wasn't ready to wait after being exposed to Apple the summer before. That professor really advocated for the Atari 800 and I really considered it, but the Apple's easier to copy floppies along with a much larger user base won me over.
I don't understand why European providers can't just host open-weight models developed by the Chinese, or distill Google/OpenAI/Anthropic models to produce their own models on the the cheap.
Nobody acts like you need to invent steel to have a steel mill.
There are plenty of European providers that do. That just doesn't get much publicity, as that's just part of normal business now and not part of AI startup hype cycles.
> The mechanism consists of a revenue-based levy applied to all commercial providers placing AI models on the market or putting them into service in Europe, reflecting their use of content publicly available online. This levy would apply equally to providers based abroad, creating a level playing field. The proceeds would flow into a central European fund dedicated to investing in new content creation, and supporting Europe's cultural sectors.
Presumably Mistral is putting forth the most pro-AI position possible for the region.
So it sounds like anyone doing what you described is at risk of a tax that will make their offerings uncompetitive.
what's the point? The Chinese, Google and OpenAI are burning money and we get to use the service. Having AI providers locally barely creates any jobs, it's an easily substitutable service and it has (contrary to the claims by the AI crazies) very few national security implications.
Steel is a great example because we don't pollute our rivers with steel mills any more either. As Milton Friedman said, if someone wants to give you steel and you give them green sheets of paper, be thankful, nothing's easier to make than paper.
What are you losing, the bragging rights among nerds on the internet? Right now Americans are paying the energy bills, Sam Altman is paying for the compute, they make no money off it, and they're even publishing the models! So if push comes to shove, we can deploy them. But until then how is that not a great deal
I postulate that if AI models get better, they also become more fungible. If you want to rule the world, you should make dumb software that takes time to learn. The world economy pretty much runs on MS Excel.
Anyone who is making money off my open source work can PAY ME if they want signed, reproducible builds.
Anyone who is not paying me can use what I generously give away for free without THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Concerned about security? Good for you, build it yourself.
You’re missing the point again, but let’s just agree to disagree because it sounds like your more concerned about money than the topic being discussed. Which is fine. It’s an opinion. I just don’t agree that it’s relevant
> That means being honest about when a pet project is just a pet project rather than talking about every POC as if it’s production ready.
And who isn't honest about it? Read the contract you have with the provider.
There is a way to legitimately expect production-ready libraries: You sign a purchase order for the right to use that code for a year (typically, or multi-year) and pay a quite substantial amount of money for that. Then you have purchased the right to expect a certain level of quality (details can be in the contract and reflected in the price).
If you're using something for free without having agreed to such a contract and paid the vendor accordingly, then you can expect exactly as much as you paid for it.
You’re twisting my argument. I’m not saying maintainers are obligated to make their code production ready. I said their READMEs should accurately represent the state of the project.
If you, or anyone else, thinks that is an unfair assessment or that I should have to pay for a README not to claim to be production ready when it’s a POC, then you had a very weird view on how much effort it takes to write the line “this is an untested beta”
> The state of expectations is usually in the LICENSE file, not in the README.
No it’s not. LICENSE tells you what you can do with the code. It doesn’t tell you the state of code.
Again, I need to reiterate my point that I’m talking about whether the code is beta, tested, etc. It costs nothing for a maintainer to specify how complete a code base is.
It’s then up to the consumers of that package to decide if they want to use it, contribute back or just fork it.
All I’m saying is too many GitHub repos are written for CVs; as if they’re meant to be consumed by Google. If something is a weekend project then just be honest and say “this is a weekend project written to solve my specific use case but PRs are welcome”. Thats better than having long blurbs that refer to the solo developer as “we” and all the other BS people stick into their READMEs to try and make their project sound better than it actually is.
All I’m asking for is a little more pragmatism and honesty in READMEs. It’s no extra effort. It’s no extra cost. And I shouldn’t have to donate to projects just to ensure they don’t lie to me.
It is interesting how every time this topic comes up it ends up with people for the most part in one of two camps: either the license is meant to be taken literally, or those who believe otherwise.
Of all the files in a repo, the LICENSE file is the one most important to take literally since it is a legal document.
So when it says something like (this from MIT license):
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
That is actually exactly what it means. There is specifically not even an implied suggestion that the software is suitable for your use.
If you want any kind of guarantee of the code being of any use to you, sign a contract and pay for it.
Unless you pay for that contract, nobody owes you any kind of hint as to whether the code is useful for anything. It very clearly says so in the LICENSE file.
It really isn’t much to ask people not to bullshit in their own README. That’s literally all I’m asking for. If you don’t want to offer software guarantees then don’t write your README like you offer it. It’s really that simple.
And your comment that I should pay every…single…maintainer of every…single…project on GitHub, just for them to disclose whether or not their project is experimental… well that’s just insane and completely misses the point of open source.
If we are talking about businesses relying on open source libraries then that would be a different matter. But not ever fscking thing being built is a VC-backed startup.
I say all of this as an open source maintainer. Just be honest in your READMEs.
A little honesty in the README costs nothing and we should be expecting more of it. And suggesting we lock that honesty behind a paywall is possibly the worst idea for open source imaginable. That simply isn’t the right way to monetise open source.
Edit: just to add, even if we were talking about software quality (which we wasn’t) paying for software doesn’t guarantee to you a better product. I could name a multitude of commercial solutions that I gave up on because the open source alternative was at least equivalent. But often even superior. And that’s before we talk about then enshitification phenomena.
Edit 2: sorry for all the edits. I should have just waited until I had proper time to reply calmly rather than commenting while doing chores and stuff around the house. My bad.
I'm not suggesting honesty should be behind a paywayll. Honesty should be upfront and it already is, in the license.
The license (most, anyway) clearly state the software is not necessarily suitable for any purpose and that's all you get.
If you require a higher level of confidence than none, then you should be paying for a support contract.
All I can say without being repetitive is that if you expect more than nothing when the license specifically says all you can expect is nothing, you might be disappointed more often than not.
This mind set of yours is a relatively recent development. Open source never used to be like that. And in fact, if it did operate the way you claimed, the open source ecosystem would never have grown into even remotely the size it is today.
And why you describe absolutely is not how any of more reputable libraries nor maintainers approach open source software.
So you might feel like you are legally correct. But you’re still completely missing the point.
It does but this is the idea that I think one has to bend or ignore the most since people always bend or ignore bits of agile.
i.e. being able to print "Hello World" and not crash might make something shippable but you wouldn't actually do it.
I think the right amount of "bend" of the concept is to try to keep the product in a testable state as much as possible and even if you're not doing TDD it's good to have some tests before the very end of a big feature. It's also productive to have reviews before completing. So there's value in checking something in even before a user can see any change.
If you don't do this then you end up with huge stories because you're trying to make a user-visible change in every sprint and that can be impossible to do.
Rather than blowing up a school full of little girls, you could deploy a swarm of thousands of fast-moving cat-sized robots armed with tasers and bolas to identify and capture targeted enemy leaders.
reply