True, but we saw alignment issues also on topics that aren't part of OpenAI's business model or business conduct. Like an agent tasked with solving build failures due to failing test cases deciding to "solve" the problem by deleting the failing tests.
I'm not convinced about this. In the article, they also say that they could feed the model with copyright law like that would fix the issue. Unfortunately, not only the LLMs have already been trained on law taxtbooks and codes, but we also have examples of people on the internet were models disregard precise instructions only to apologize later.
Note that this is not to be seen as an excuse for OpenAI to avoid responsibility, just like parents are responsible for damages caused by their kids.
While SHA2 and SHA3 use very different algorithms, the purpose of the SHA standard stays the same. Or maybe I'm missing some official document from NIST saying otherwise that you could point me to?
Interesting. Anyway, since they're going through the pain of changing the hash function, why not using the latest standard? SHA3 has been standardized for some time now, and using SHA256 isn't any easier than using SHA3-256.
But, which kind of bribe are we talking about? How could it work out in practice for an AI to acquire something valuable, and at the same time prevent it's human operators from taking it without its consent?
If you got overwhelmed in trying to understand how to do it, just do it the easy way: create a ZFS pool of two drives of identical size in mirroring. Then, make sure to have regular scrubs (this means ZFS will regularly check all files for corruption, and recover from eventual errors), use your OS' task scheduler (e.g. Systemd or cron) to run this once a month. This should be sufficient to protect you from bit rot.
~30 years old here, and I can confirm I risked and suffered data loss multiple times. I remember when I still was at my parents house during university I had in mind to build a NAS to properly host the family's photo archive (main reason was bit rot protection, which we experienced, but I was planning for a proper backup as well). But I kept procrastinating. Then, I risked losing it due to a distraction. After spending one week to recover it, building a proper solution to host and backup it became top of my list.
Unfortunately, your comment reminds me that car manufactures aren't Google or Apple either, and still it seems that modern, high-end cars have a tendency of collecting more than what's needed for the car to remain in good shape or be diagnosed. I guess we became so defeatist when more and more companies started realizing they could make extra profit by collecting data from their customers.
If you have lots of data, I would suggest using a filesystem designed for this, like ZFS or BTRFS. You would still have to spend in storage though, as ultimately protecting from bit rot requires redundancy.
I also struggle to reconcile these things, I guess the only way would be to try and see if it works for me, without caring too much if it works for other people on the internet. I would just like to add that, DwarfStar's author (Salvatore Sanfilippo) is a strong supporter of the idea that you shouldn't read the code, and he says he never read DwarfStar's code. And still, it seems that this project is much more than PoC and actually both usable and useful for people doing local inference (I didn't try it myself, but I saw a lot of positive comments about it). Could be that the crucial point is in how we use those models: instead of giving it a general goal (e.g. build me an inference engine) Sanfilippo, being an experienced programmer, kept pointing the models in the right direction. He also read the papers related to the models he was programming support for in DwarfStar, so that, when he worked on optimizations, he knew what should be done instead of prompting a general "please optimize this". So, I would say that, if you let the agents work on a "feature by feature" basis instead of trying to on3-shot things, you get much better results. Could also be that, by attempting to one-shot large projects, the model starts coding badly due to context window exhaustion.
Sorry for the not so well written comment, I was just throwing in some ideas.
Yes, but as l9ng as there's no clone, they're good. On the potential clone side, I guess many will be put off by the fact that "there's already OpenRouter". Also, a clone would need to find a way to make existing OpenRouter customers to switch, which isn't easy.
Yes, you can get better pricing if you do it yourself. But the true advantage of OpenRouter is that, in a space where there's a new model being released every week, you can easily switch to whatever model is best at any given time without having to set up accounts with multiple providers. Or you can just experiment with the latest release. Their product is the convenience. Of course if you decide to only use a specific provider or two, then you don't need OpenRouter.
I agree it's not a binary thing, it's just that, by how the parent comment is worded, looks like for them anything above the line of misery is OK. But maybe my interpretation is wrong.
IMO there's a big difference between using AI to write code and using it to review your code. In the latter, you know the code well (you are the one who wrote it), and so it is much easier to understand if AI suggestions are good or hallucinations. In the former case, realizing when the AI is making mistakes is harder, because you don't have the full context anymore.
You should really look at studies on how happy employees are much more productive than unhappy ones. And the trend continues way above the bare minimum of not being miserable.
You should read my other comment where I explain better what I meant. I also don't like how some programmers like you tend to think they're superior to others ;)
You're right, running now a farm that is profitable and can stay on the market is very different from doing so 200 years ago. But knowledge is just one aspect. The other aspect I mentioned is having less people in the field than what the market asks for. In the specific case of farmers, I think that modern farms are so much more efficient that we need way less than before, even if the world's population grew. So, while there's a gap between the knowledge required and the earnings, I think this can be explained by farms having a much greater output now, and so the market doesn't ask for more farms than what we have. This could be false at a global scale, but I think it is true at a country-level scale in most of the developed countries. Hence why farmers aren't paid much in those countries.
The basic services that keep us alive (e.g. farmers producing our food) tend to also be "easy" (it is physically demanding, but doesn't require years of study to start and you quickly learn by doing). This also means that the vast majority of people would be able to do this kind of jobs. Our economy pays more for scarcity, i.e. jobs that are in demand and at the same time require more qualification, so that the number of people needed in that position tends to be less than the current amount. Both views have sense, they just start from two different points.
Strange that in the prior art they didn't list DwarfStar, as it is able to run the same model (probably quantized differently though) in less memory. Maybe the author isn't aware of it?