In theory, sure, an identity verifier could issue you you a bunch of single use JWTs signed by them that contain `{"over18":"true", "nonce": 12748583..., "iss": "<issuerurl>"}`, signed by their key. A relying party just needs to know the public keys of all the issuers they trust, and can consume this JWT, verify it, and never learn anything about your IRL identity.
The important things are that they must issue a bunch at once. (Otherwise, correlating who you are becomes easy). They must keep no record tying nonce or the full JWT to an individual identity. Something user local or otherwise trustworthy (not keeping logs), needs to hold on to these, and send them out as needed, being very very careful never to reuse one (as that would enable cross site tracking). Lastly a relying party must be required to trust many issuers, not just those they are colluding with track users across sites with this.
The European Commission actually proposed pretty much exactly this system, also with a variation where instead of revealing the signed token, a ZSNARK proof (that you possess a validly signed token with the over18 attribute from a specific issuer) could be given to the relying party instead (to make it impossible for issuer and relying party to collude to release your identity). Many people here seemed to not like it.
I'd argue they are not commutive in regexes either, at least as implemented in practice. Implemented regexes favor the leftmost alternative even when both sides of the alternative match. This matters in cases like: capturing groups, and backtracking implementations. There absolutely are cases where one ordering of alternatives could yield catastrophic backtracking for some input, while the other will avoid it completely.
I personally don't like this at all. This means that regex engines that try to generate optimized matching code for an expression can end up generating suboptimal code if you don't want alternative order to matter, since the engine needs to keep that invariant, except in the case when it can prove that the alternatives won't overlap, and a later one can be checked in constant time. If both are true, it is legal to reorder them to do the constant time check before the big complicated wildcard-filled alternative.
But personally, I have never written a regex where I actively cared about the alternative evaluation order. I've used some other people made where order is important but never written one myself.
I'd love to be able to tell the engine "feel free to swap the evaluation order of my alternatives while optimizing", but few if any such engines offer that as a feature.
Now I get that PEGs have commutivity problems are that are different from regexes', which make the issue worse, but that doesn't mean regexes do things right either.
If the compiler can find any operation prior to the null check that would be UB if the value is null (even if it is something that in assembly would be harmless, like performing pointer arithmetic on it), the compiler is allowed to assume the pointer is not null, and thus omit the null check. This could then lead to something that will in practice cause problems like dereferencing the pointer.
Compilers keep taking more and more advantage of inferring that a values in variables cannot be `x`, because if it were than some previous usage would have been UB. When people file bugs to complain, the compiler authors point at the spec which allows them to assume that UB behavior never happens, so the compiler behavior is legal. The only counterargument is if the compiler has chosen to document some specific behavior for this UB (possibly only with specific flags enabled) in which case the compiler testing that scenario as proof of impossibility is indeed a bug (when the required flags are set).
A combined MPU and MCU architecture isn't that exotic. ST microelectronics currently sells a single chip with that contains a two core Cortex A7 Microprocessor combined with a microcontroller. Admittedly more tightly integrated with ability to communicate via shared memory.
The "custom os" part could also be done easilly enough with the correct approach.
Specifically systemd has a less-known feature known as system extensions intended for basically exactly these sort of scenarios. These system-extensions are basically disk images containing files in /usr and/or /opt that can be dynamically overlaid on the existing filesystem (the intent is that these are purely additive). Systemd also intends that all os provided configuration live in /usr, with /etc existing only for machine specific or admin applied configuration. (And which should enabling overriding anything specified by the package or OS.)
System extensions when used default /opt and /usr to be read-only, but you can enable mutability if you having write routing directories or symlinks in the right spot.
So for userland this whole os profiles things could literally just be a set a of system-extensions, a distinct /etc folder, and distinct set of write redirect directories for each. An initramfs can simply bind mount the /etc directory, and add the correct write redirection symlnks before systemd starts. Rolling back a profile is simply wiping its write redirection and /etc folders. If you also want each to potentially have distinct device trees and/or customized kernels, that would need additional bootloader work on top, but nothing that feels too extreme.
Now in reality, since not everything support systemd style configuration, these OS profiles would probably need to construct an initial /etc by copying files from a base-os template, and then copying in anything included in the system extension images (which can have these as systemd will ignore such folders), but that is straightforward enough.
> A combined MPU and MCU architecture isn't that exotic. ST microelectronics currently sells a single chip with that contains a two core Cortex A7 Microprocessor combined with a microcontroller. Admittedly more tightly integrated with ability to communicate via shared memory.
Don't underestimate the value of that integration.
With the hybrid architecture chips you get the vendor controls for managing the MCU with supporting documentation. ST is good at this.
This isn't the same thing. It's two chips running side by side. It's possible to set it all up so that the Linux chip can control everything you need to manage the MCU, but it's not easy. There are a lot of edge cases to think about and things that need to be handled manually.
Absolutely every laptop uses this same architecture, you can even find the source code of the MCU firmware for Framework laptops and Chromebooks (chromium-ec).
> A combined MPU and MCU architecture isn't that exotic. ST microelectronics currently sells a single chip with that contains a two core Cortex A7 Microprocessor combined with a microcontroller. Admittedly more tightly integrated with ability to communicate via shared memory.
Going with an SoC is much simpler than trying to set up custom communications between two processors, I'm not sure why they didn't think of that.
I must be missing something, since I'm not really sure that follows. Initially neither AV nor AR models knows anything about how activations map to explanations or how explanations map to activations.
As far as I can tell, the only reason that the explanations even resemble human speech is that AV and AR start off based on a trained language model. If we instead trained the same model architecture from scratch as AV and AR, they would eventually converge to some round trip format for activations, but it probably would be completely unintelligible and look only like human speech in so far as many of the tokenizer's tokens look like words or word fragments.
This whole process seems to rely on the fact that the text AR's output will still strongly favor output sentences that seem to make sense, rather than contradicting learned facts, etc. So it will favor mapping activations to plausible sounding text in ways where patterns can consistently hold across most of the training data. There absolutely is a risk that it will learn the wrong things for certain activation subpatterns like swapping concepts especially if none of the training data included a set of activation sub patterns that would help distinguish them the right way around.
> I think many people already mentioned it, but I also don't feel to good about non-boxed unions not being the default. I'd personally like the path of least resistance to lead to not boxing. Having to opt-in like the current preview shows it looks like a PITA that I'd quickly become tired of.
The problem is that the only safe way for the compiler to generate non-boxed unions would require non-overlapping fields for most value types.
Specifically the CLR has a hard rule that it must know with certainty where all managed pointers are at all times, so that the GC can update them if it moves the referenced object. This means you can only overlap value types if the locations of all managed pointers line up perfectly. So sure, you can safely overlap "unmanaged" structs (those that recursively don't contain any managed pointers), but even for those, you need to know the size of the largest one.
The big problem with the compiler doing any attempt to overlap value types is that if the value types as defined at compile time may not match the definitions at runtime, especially for types defined in another assembly. A new library version can add more fields. This may mean one unmanaged struct has become too big to fit in the field, or that two types that were previously overlap compatible are not anymore.
Making the C# compiler jump though a bunch of hoops to try to determine if overlapping is safe and even then leaving room for an updated library at runtime to crash the whole things means that the compiler will probably never even try. I guess the primitive numeric types could be special cased, as their size is known and will never change.
Cost tracking is used if you connect claude code with an api key instead of a subscription. It powers the /cost command.
It is tricky to meaningfully expose a dollar cost equivlent value for subscribers in a way that won't confuse users into thinking that they will get a bill that includes that amount. This is especially true if you have overages enabled, since in a session that used overages it was likely partially covered by the plan (and thus zero-rated) with the rest at api prices, and the client can't really know the breakdown.
Right. Claude models seem to have had very limited prohibitions in this area baked in via RLHF. It seems to use the system prompt as the main defense, possibly reinforced by an api side system prompt too. But it is very clear that they want to allow things like malware analysis (which includes reverse-engineering), so any server-side limitations will be designed to allow these things too.
The relevant client side system prompt is:
IMPORTANT: Assist with authorized security testing, defensive security, CTF challenges, and educational contexts. Refuse requests for destructive techniques, DoS attacks, mass targeting, supply chain compromise, or detection evasion for malicious purposes. Dual-use security tools (C2 frameworks, credential testing, exploit development) require clear authorization context: pentesting engagements, CTF competitions, security research, or defensive use cases.
----
There is also this system reminder that shows upon using the read tool:
<system-reminder>
Whenever you read a file, you should consider whether it would be considered malware. You CAN and SHOULD provide analysis of malware, what it is doing. But you MUST refuse to improve or augment the code. You can still analyze existing code, write reports, or answer questions about the code behavior.
</system-reminder>
The file locking approach is one used by centralized version control systems, and are mostly used in the everybody commits directly to trunk style of development. In those environments merging isn't much of a thing. (Of course this style also comes with other challenges, especially around code review, as it means either people are constantly commit unreviewed code, or you develop some other system to pre-review code, which can slow down the speed of checking things in.)
This approach is actually fairly desirable for assets types that cannot be easily merged, like images, sounds, videos, etc. You seldom actually want multiple people working on any one file of those at the same time, as one or the other of their work will either be wasted or have to be re-done.
The important things are that they must issue a bunch at once. (Otherwise, correlating who you are becomes easy). They must keep no record tying nonce or the full JWT to an individual identity. Something user local or otherwise trustworthy (not keeping logs), needs to hold on to these, and send them out as needed, being very very careful never to reuse one (as that would enable cross site tracking). Lastly a relying party must be required to trust many issuers, not just those they are colluding with track users across sites with this.
The European Commission actually proposed pretty much exactly this system, also with a variation where instead of revealing the signed token, a ZSNARK proof (that you possess a validly signed token with the over18 attribute from a specific issuer) could be given to the relying party instead (to make it impossible for issuer and relying party to collude to release your identity). Many people here seemed to not like it.
reply