A restart of the process does not necessarily mean reverting the model state. I don't know why you would even do that, because you'd lose all the progress you made.
this! - the reason Zig defaults to one semantic analysis thread is due to current (to be improved) limitations; some ideas for Zig also will require one compilation unit - the restricted function pointers proposal being a good example: https://github.com/ziglang/zig/issues/23367
The bun team tried to parallelize Zig's semantic analysis a while back - and it DID compile about 4x as fast... YET the builds were no longer deterministic, which is a hard requirement for lots of things. More effort will need to be spent here than naively adding a thread pool. Hopefully Zig's Sema.zig gets faster, but Rust is also super slow at compiling and needs to improve. Oh - one last thing to note, Zig has very fast debug compilation and incremental compilation, it's a real nice thing to work with that you simply can't approach in most other languages right now.
It's reasonable to believe not, because OpenAI has money and is using it to get what they want. Example: OpenAI is declining the 1 million USD from the navier stokes millennium problem prize, which is essentially a "bribe" because it would now cost one million USD to go with the other side in this controversy.
I used a similar (same?) service that claimed no data was uploaded and "all processing happens on-device"... I decided to record network packets with wireshark and found out the tool DID upload a significant amount of data (about 2 megabytes) through its lifetime. I wouldn't trust these tools farther than you can throw them.
I have not, do not, and will continue to not allow my data to be used for AI training... Yet for some reason my blog website is still scraped by some AI data slurper every 10 seconds. If 99% of people don't care (or know) about their data being ingested, it doesn't justify the scraping, because there is still a (rightly infuriated) 1% who do care.
My bad - I misread your original post as general company announcements, rather than feature announcements. Now my question is, if your internal staff are not requesting these features and are struggling to adapt fast enough, how useful are they? To your last question - what do you mean by velocity? Velocity is speed and direction. You may have speed, but beware the brownian motion that is stochastic predictive models, as that will give you net zero velocity. I have my goals and know what I am doing, and to be frank, it matters more that I read and understand my own code than race to a local optimum.
Do you also have a graph for more useful metrics, like number of requested features delivered? Commits, lines of code, headscratch count... there are a lot of metrics you can use, but LLMs are notorious for increasing code verbosity - which adds noise to the already imprecise metric you linked.
I'd imagine that OpenAI would try to stagger their announcements, rather than publishing them recently close to each other. Is this because their previous post (about navier stokes problem) was met with controversy?
That's like comparing apples to pears. OpenZL is not general purpose. You specify a format for data and it compresses that format. Specifying a general "could be anything" format would be interesting, but I doubt it would compress as well.
Correct me if I am wrong, but I'm pretty sure they could get away with this because nitter is not an archival software, but rather a frontend or alternative twitter proxy.
We can't find someone to blame for forces of nature. This includes an earthquake, tsunami, etc. Insurance can help recover from these events, but nobody is "responsible" for the events happening. This may or may not include healthy trees falling. LLMs are not a force of nature, and we can and do expect them to have erroneous output. We can and do assign responsibility to the humans who use LLMs. Again, they are not a force of nature. We control them, we give them the ability to do bad things, so it's pretty obvious that there would be responsibility and blame attached for when things go wrong.
With AI, we give it the ability to do things. As we can give it this ability, we are responsible for what it does with that ability. LLMs are predictive models, and while we can expect things to go right, we know that things can also go wrong. As such, it is our responsibility to limit or sanitize their output. If you are the one giving unrestricted and unsanitized tool access to a large language model, then you are the one who is responsible for the consequences of that access - good or bad.
LLMs are fully dependent on humans; compute capability, memory usage, the inference software... but also the harness, which allows for the "tools" like unrestricted internet access or shell. This means that LLMs are *not a force of nature* - because of this, *humans are responsible*. We can prevent these breaches of containment, thus we are responsible if or when it happens, because - no matter how "unlikely" - things can and do go wrong, and someone still thought it would be worth whatever risk to enable these unsanitized tools.
Do you own the dog? You are still responsible, no matter how unlikely.
> giving AI a harness with a root shell and unrestricted internet access
Yes, this is exactly the issue. You assume responsibility when you provide an option for something to go wrong, no matter how unlikely. Is it rare that my tree falls on my neighbor's house? Maybe... But I would still be responsible.
Exactly. If your website could be attacked via SQL injection, that was a problem that directly affected you - and you were motivated to fix it. When the victim is the masses or small organizations (not the company that does the attack) they are not as motivated to fix it... The important thing is that the lack of sanitizing is what allowed this; you also don't push the blame on a monkey banging on a typewriter when you publish each result without reading it.
Surely you mean the "time spent," not the "speed" - as an interpreter would have an overhead, not magically speed up WASM execution. Somewhat related note, we need better tools for PGO within native compiled programs.
Caffeine is especially interesting, as it is commonly consumed and there are incidents where people are hospitalized because they accidentally ate too much - https://pmc.ncbi.nlm.nih.gov/articles/PMC8824417/ (referencing the 6000 mg here)
seems to me like "private" is a good descriptor - I also have a set of "private" test cases - and they are kept private on purpose so they aren't scraped and fine-tuned on.
> Overall, our results indicate that current language models possess some functional introspective awareness of their own internal states. We stress that in today’s models, this capacity is highly unreliable and context-dependent; however, it may continue to develop with further improvements to model capabilities.
> Experts worry that such studies are way ahead of necessary guardrails and regulations. AI has also been known to fly off the rails autonomously. An OpenAI agent recently went rogue and hacked Hugging Face.
Even if 99% of the population wanted to slow down the improvements being made to (and/or immoral/illegal/unethical use of) AI - assuming it will start to improve superlinearly - I don't believe that the remaining 1% of the population could be prevented from doing so: papers are published, downloaded, and experimented on without restriction... It's possible this growth could be slowed by the proliferation and distribution of local LLMs (decreasing profits for those who primarily train models)... I don't think these scare tactics in the article will prevent the training and feared evolution of AI. :P
Indeed - if you need to be absolutely confident about security and privacy, run a model locally and audit the inference software and potential tooling.