How is this an OS? I thought it might be a kernel developed in rust with a python ffi api, but it's nothing to do with any of that.
32,238 karma · joined January 3, 2008
Mozilla has taken a strong stand against the prompt api.
Gemma 4 E4B is a much better model, but it's too large to simply download and run everywhere.
IMHO, this is jumping the gun. Google's going through a lot of effort to release a model that will give everyone a very poor first impression of what on-device models are capable of, souring it for everyone for a long time afterwards. It would be better to wait until a smaller, better model ships before doing this.
But, yeah, I’m a nobody that has been blogging (very sporadically) publicly (and writing at length on forums like this one, with various handles loosely tied to my real identity) for twenty or more years (and by virtue of not trusting 3rd parties to host my content, most of it is actually still up) and Opus 4.6 (didn’t try 4.7) got me on the first try with just two paragraphs of an unpublished draft post (though it couldn’t come up with a convincing reason as to why it thought it was me).
Gemini and ChatGPT both clearly go off the subject matter rather than the stylistic clues; for the specific blog post I fed it which included mentions of “decoding” and “deciphering” and spoke of a tranche of legal documents (ok, it was the Epstein files, which I have been working on decoding), Gemini and ChatGPT both guessed “Molly White”, who seems to be a crypto-adjacent (currency not the real thing?) technical writer, and gave explanations that actually did explain why they arrived at that (wrong) answer.
So it seems Opus is indeed a bit special in this regard (and not limited to the latest 4.7 release)!
—-
What I would be more curious about is how well they can identify (open source) developers from their code. I’ve possibly publicly published more tokens in the form of OSS code than prose over the same period of time, in multiple languages and for completely different applications and environments. I’m sure there are style stylometric quirks associated with my coding style that persist across codebases, (though possibly somewhat stunted when contributing to others’ codebases to comply with the respective projects’ standards and styles) that should make it possible for an LLM that’s ingested code (and commits) to guess who’s who.
Edit:
Reading this self-same comment: I am apparently obsessed with parentheticals. Maybe my writing is more distinctive than I realized!
But what about when the playful profile reinforces usage of emoji and their usage creeps up in all other profiles accordingly? Ban emoji everywhere? Now do the same thing for other words, concepts, approaches? It doesn’t scale!
It seems like models can be permanently poisoned.
(I have many close friends that are similarly pedantic though for other reasons.)
Anyway, the site lets you categorize by processing method. All the acid cure options should meet your requirements, no?
I.E. just because police don’t “waste” time investigating a crime with $1000 of damage to your personal property does not mean they won’t dedicate the time to pursue $200 in losses for the local mega mart.
After Ives was fired/forced out/decided to leave to pursue his creative vision.
Libgen was a much better option.
(Also this comment is ai generated so I’m not sure who I’m even asking.)
In all cases, GPT 3.5 isn’t a good benchmark for most serious uses and was considered to be pretty stupid, though I understand that isn’t the point of the article.
More seriously though, you're supposed to use separate vaults (with the same keys, where "keys" is the name of the secrets, not the decryption keys) for testing/staging/production, e.g. perhaps secrets.{testing,production,staging}.json and the same secrets.{testing,production,staging}.key for the decryption keys, and store both the username and password in them (after all, it's just an encrypted, glorified KV store) so that you don't have to hard-code any usernames and conditionally load them based on the environment in your code (so db:username is one "secret" and db:password is another (actual) secret).
The secrets vaults (the secrets.json files) are non-sensitive and can be versioned and pushed to your server the same way you push the binaries. Now how you move the secrets to the server is up to you. You could do it the old-fashioned way and just have it as an environment variable, in which case even when your env vars leak at least you haven't leaked your api keys, only the key to decrypt them (which you'd then rotate), but that's not a recommended option. Ideally you'd instead use whatever secure channel you use to init/stage the servers to begin with to transfer the secure key files - the key files are generally immutable, even as the secrets change, so you only have to do this once (ideally via a high-friction, high-auth mechanism, for most people not at FAANG scale, probably manually).
You can also use whatever additional layer of abstraction on top of the symmetric SecureStore decryption key you like. For example, you could asymmetrically encrypt the keyfiles and then each host would decrypt it with its own private key, or have a secrets side channel that's just used to obtain the static decryption key over the local network, or use your operating system's encryption facilities to transmit it, whatever works for you at whatever point on the complexity/security curve you desire.
(These are all just options, none are official recommendations.)
I didn’t get a chance to do a write up but the golang port is here: https://github.com/neosmart/securestore-go
The approach to crypto is very different, we went with what’s very well understood and very well supported on all platforms with little or no dependencies (eg we can use web crypto in JS frontend or backend with no external libs or crypto JS library nonsense).
The original .NET and Rust code is from over a decade ago and carefully architected (well before vibecoding was a thing), the secrets are stored in a human readable (json) vault that can be embedded in your binaries or distributed alongside them and be decrypted with either password-based or key-based decryption (or both).
The rust repo has the most info: https://github.com/neosmart/securestore-rs
I just migrated to MS artifact signing and, thank the lord, had an actually easier time getting verified than I did with the Sectigo and Comodo in the past. I’m sure I’m not representative of anyone else’s experience but having already had a developer account (with a different email and without an Azure account!) that I had already been using for the Microsoft Store might have helped, as well as the fact that I had a well-established business history (I’ve heard businesses younger than 3 years can’t get verified??), but reading all the comments here makes me very uneasy about the future.
It’s good to know the HSM route isn’t a complete non-starter. The main reason I panned it is that when I started looking into this I found that a number of companies that had previously offered the HSM route had done a bait and switch and were now keeping custody unless you were big enterprise (meaning willing to put up with 10k/yr fees). I did find a few that would allow OSS devs to sign their work, but read horror stories on Reddit and elsewhere about their freezing the account and issuing no refunds if you ask them to issue the cert in the name of your LLC or corporation instead of with your personal name (which I expressly did not want). Also, they actually were more expensive than Azure artifact signing even after the HSM cost was taken out.
Anyway, even if you could get your own cert it would be same thing: MS could revoke or blacklist your indicate cert (though usually the grounds for doing so are much less shaky than your account being suspended for vague “tos violations”)
No one is calling an executive meeting to discuss banning an OSS dev’s account.
Ideally they'd always carry an "AI-generated" flag (in the db and in the frontend) until manually reviewed (or never) by a human. If anything, this is actually in AI proponent's favor as it would let you periodically regenerate or cross-validate (a subset of) the AI contributions some years down the line when newer and better models are released!