gizmo686

Even programs are just specifications by that standard. When you write a program in C, you are describing what an abstract C machine can do. When the C compiler turns that into a program it is free to do so in any way that is consistent with the abstract C machine.

If you look at what implementions modern compilers actually come up with, they often look quite different from what you would expect from the source code

I think there are two distinct attack types for LLMs. Jailbreaking is what most people think of, and consists of structureing a prompt so the LLM does what the prompt says, even if it had prior context saying not to.

The other type of attack would be what I would call "induced hallucinations", where the attacker crafts data not to get the LLM to do anything the data says, but to do what the attacker wants.

This is a common attack to demonstrate on neural network based image classifiers. Start with a properly classified image, and a desired incorrect classification. Then, introduce visually imperceptible noise until the classifier reports it as your target classification. There is no data/instruction confusion here: it is all data.

The core problem is that neural networks are fairly linear (which is what makes it possible to construct efficient hardware for them). They are, of course, not actually linear functions, but close enough to make linear algebra based attacks feasible.

It is probably better to think of this sort of attack in term of crypto analysis, which frequently exploits linearity in cryptosystems.

The depth of LLM networks make this sort of attack difficult; but I don't see any reason to think you can add enough layers to make it impossible. Particularly given that there is other research showing structure across layers, with groupings of layers having identifiable functionality. This means it is probably possible to reason about attacking individual layers like an onion.

This problem isn't really unique to AI either. Human written code has a tendency to be vulnerable to a similar attack, where maliciously crafted data can exploit the processor to do anything (e.g buffer overflow into arbitrary code execution).

I've implemented trits a bunch of times and have never regretted it.

How you get 5 possible values into a tri state Boolean is beyond me though.

It's not clear from the article, but "niche optimization" does not mean "optimization that is only useful in a very specific circumstance".

It is a specific optimization based on the idea of storing one type inside of another type by finding a "niche" of unused bit pattern(s) inside the second type.

It has far more useful application than a tower of Option 254 deep.

I doubt they were thinking about Option<bool> when making niches work like this.

Option<NonZeroU32> seems like a much more reasonable to justify this with. Also, enums can easily have invalid bit patterns that are unused without there being any specific bit that is always available. All you need is a single variant of the enum to have a free bit, and you have a niche to shove None into.

I'm surprised that trinary logic has not become a standard part of standard libraries yet. Almost every project I have worked on ends up with some form of a yes/no/maybe abstraction.

No. SELinux is based on the Linux Security Module framework, which places explicit hooks at key points within the kernel.

They also operate under pretty fundamentally different philosophies. Seccomp is based on a program dropping its own permissions. SELinux is based on a system integrator writing an ahead of time policy restricting what a program can do.

You can mostly do that with Seccomp on Linux (I have no experience with FreeBSD).

Child processes inherit the restrictions from the parent. You can therefore have the parent fork, setup it's rules, then exec. This is exactly how syscall filtering (and a bunch of other lockdowns) are implemented in SystemD

Refundable tax credits are a thing the government knows how to do. If a negative income tax law was written to allow refunds to people who owe net negative taxes, the IRS could do it.

This isn't a case where you need bug free software. This is a case where the frequency of fatal bugs is directly proportional to the support cost. Fix the common bugs, then write off the support for rare ones as a cost of doing business.

The effect of cheap robo support is not reducing the cost of support. It is reducing the cost of development by enabling a more buggy product while maintaining the previous support costs.

LLMs outputting code that doesn't compile is the failure mode you want. Outputting wrong code that compiles is far worse.

Setting aside the problems of wrong but compiling code. Wrong and non-compiling code is also much easier to deal with. For training an LLM, you have an objective fitness function to detect compilation errors.

For using an LLM, you can embed the LLM itself in a larger system that checks it's output and either re-rolls on errors, or invokes something to fix the errors.

How does a TPM stop people from lying about their age?

Damage scales with the 4th power of weight.

From what I can find, the standard weight limit for a truck in 20 tons per axle (less when multiple axles are close together).

In contrast, the average weight for a car is a bit under 4 tons (even for SUVs). Even a pickup truck is under 5.4 tons. Since these have 2 axles, that comes out to every class except loaded freight trucks having under 2.7 tons per axle on average. So a freight truck acting at the legal limit (without tandem axles) would be over 7.4 times as heavy per axle as a passenger pickup truck. Applying the 4th power law, this means a single maximally loaded truck causes about 3000 times (300,000%) as much damage as an average pickup truck; and 10,000 times (1,000,000%) as much as an average SUV. In contrast, the difference in damage caused by an average SUV and an average sedan is only about 40%

https://www.autoinsurance.com/guide/average-car-weight/

All distributions involve maintaining patch sets. The question is what the marginal burden of this particular patch is.

All models are wrong, some are useful.

Yes, there are theoretical issues with assuming PRNGs are truly random. However, there are also theoretical issues with assuming that Newton's law of universal gravitation is true.

I am confident is saying that more experiments have gone wrong due to not considering relativity, than have gone wrong due to the proper usage of a statistically sound (even if not cryptographically so) PRNG.

I also suspect that both classes of errors are dwarfed by improper usage or non sound PRNGs.

For almost all practical purposes, a decent prng is just as good as a csprng. Cryptographic security only becomes relevant in an anverserial situation. Otherwise, you would need whatever weekmess exists in the prng to be somehow correlated with what you are trying to measure.

Alternatively, we are gatekeeping basic decency behind having a diagnosed disability.

Dog tags are easy to replace. Microchips are not. Having a level of indirection allows the meaningful contact information to be updated as needed.

Also, chromosome count is not as stable as you might intuitively think. There are hominidaes alive today with 48 chromosomes.

There are human men alive today without any Y chromosomes that present with standard male phenotypes without needing any medical intervention. Currently, the biggest symptom of this condition is infertility (which is often the point where most people learn they have it). However, on evilutionary timescales, it doesn't seem that far off for the remaining needed genes to migrate over as well. On a human timescale, it doesn't seem that far off for us to medically solve the infertility issue; although I imagine the ethics rules would prohibit such treatment if it leads to xx-male offspring.

Having said that, while chromosomal sex determination is not omnipresent, it does seem to be much more preserved than chromosome count.

Because kilo- already has a meaning. And both usages of kilobyte were (and are) in use. If we are going to fix the problem, we might as well fix it right.

I had a similar problem a few years back. Our decades old system had a poor architectural system baked in that was causing major performance issues in some cases. Fixing it within the core was straightforward, but ended up violating an assumption that almost every module we had made.

After two attempts at fixing it failed (due to getting hopelessly out of synch with mainline), we put the fix behind a flag and setup updated our CI to run the test suite with both modes of the flag; and to only fail for new test failures.

Generally speaking, liability for a thing falls on the owner/operator. That person can sue the manufacturer to recover the damages if they want. At some point, I expect it to become somewhat routine for insurures to pay out, then sue the manufacturer to recover.

I would be surprised if that was what they were actually looking at. They are an established insurance company with their own data and the actuaries to analyze it. I can't imagine them doing this without at least validating a substantial drop in claims relating to FSD capable cars.

Now that they are offering this program, they should start getting much better data by being able to correlate claims with actual FSD usage. They might be viewing this program partially as a data acquisition project to help them insure autonomous vehicles more broadly in the future.

> The Hippocratic oath says that a physician should do no harm

No it doesn't. Such a standard would make the practice of medicine impossible, as all treatments have some risk of harm.

What is relevant to this discussion is the below excerpt of the modern form of the oath:

> I will apply, for the benefit of the sick, all measures which are required, avoiding those twin traps of overtreatment and therapeutic nihilism.

Germline editing is banned everywhere (with some exceptions for laboratory testing that will not result in an actual human).

Nothing about this treatment is targeting the germline.

Edit: Also, high cholesterol tends to become a concern for old people, who tend not to reproduce.

That is why we do long and expensive trials before approving any medication for use.

Having said that, we have we been medically lowering people's cholesterol levels for decades, and the evidence seems pretty clear at this point that it is a net health benefit to those for whom treatment is indicated.

It is not at all obvious that targeted gene editing would be more disruptive to the body compared to flooding the body with a drug that happens to interfere with the one part of the process that we found a drug to interfere with.

Particularly if we are editing the gene to match a form that is already present in much of the population.

High cholesterol is well documented to be heritable. Perhaps more relevantly, even if they would work, lifestyle changes have a significant patient compliance problem, which significantly reduces their effectiveness.

There is a more reasonable brother argument to could make, which is that we have well tested and effective drugs available today for managing cholesterol. Any new treatment would need to clear the bar of being better than those (in at least some circumstances) to be put into wide use. This bar may cleared by the fact that existing treatments often have adverse side effects.

Further, the one time treatment aspect is actually a demerit in some ways, as one cannot stop the treatment if there is an adverse effect. This means that the safety profile would need to be much better than us typically required. And proven over a longer timeline.

Of course, this is all concerns about approval and widespread deployment. We are still in the early human trial phase, where much more risk is accepted (subject, of course, to ethical guidelines).

It would give you a certificate chain which may authenticate the onion service as being operated as who it purports to. Of course, depending on context, a certificate that is useful for that purpose might itself be too much if an information leak

I've seen another type of "let projects fail" in my career done by middle managers in a large project. Essentially it takes the form of them saying "the larger project we are working under is probably going to fail. When it does, I want our component to be useful for whatever comes next". And, the surprising thing is that this often worked. The project itself fails, but most of the work done on it still ended up being used.

Letting people fail and letting projects fail seem fairly different to me (at least for large projects).

There have been a bunch of times in my career where I've allowed people under me to "fail". Often times, an individual failing at something is just not that expensive; while being highly educational. Sometimes, it turns out that there approach actually worked, and we as a group gained a new bit of institutional knowledge.