You're conflating terrorism with irregular warfare. The Oradour-sur-Glane massacre was terrorism committed by regular forces; the French resistance blowing up a German supply train was non-terrorist action by irregular forces.
The presupposition behind that question is that immigration is a necessary evil to be limited as much as possible. I am not American, but that strikes me as an ironic position for Americans to take.
In my experience these models work fine using another language, if it’s a widely spoken one. For example, sometimes I prompt in Spanish, just to practice. It doesn’t seem to
affect the quality of code generation.
Thank you. +1.
There are obviously differences and things getting lost or slightly misaligned in the latent space, and these do cause degradation in reasoning quality, but the decline is very small in high resource languages.
It just can’t be a case simply because how ML works. In short, the more diverse and high quality texts with reasoning reach examples were in the training set, the better model performs on a given language.
So unless Spanish subset had much more quality-dense examples, to make up for volume, there is no way the quality of reasoning in Spanish is on par with English.
I apologise for the rambling explanation, I sure someone with ML expertise here can it explain it better.
I saw a curious post recently that explored this idea, and showed that it isn’t really the case. The internal layers of the model aren’t really reasoning in English, or in any human language.
Translation in/out of human languages only happens at the edges of the model.
Internal layer activations for the same concept are similar regardless of language, while activations at the top/bottom layers diverge. Meanwhile the pattern is reversed for same language different content.
So we do at least agree on the fact that quality of human language <-> embeddings transition depends on how good target language is represented in the training dataset?
Even if it happens at the edge, on every conversation turn, I may assume non captured small subtleties of meaning over time can accumulate into significant error.
The agent may be translating to English behind the scenes. There are all kinds of hacks layered on top of the underlying models. But however exactly it works, it’s clearly not the case that these things only make use of Spanish training data when you prompt them in Spanish.
Lets take a language with orders of magnitude less training data, like Nahuatl. The following is what happens if I ask Claude Code in Nahuatl to give me an example of a simple program that I can execute inside a web browser (avoiding any direct keyword prompts like 'Javascript' or 'Hello World'). Interestingly, it responds in Spanish. I doubt that it has any relevant training data in Nahuatl. (Apologies if the Nahuatl is wrong – I just used Google translate.)
¿Uelis techmakas se neskayotl tlen se programa tlen amo ouij tlen ueliskia nijchiuas ipan se navegador web?
-----
Entiendo tu pregunta en náhuatl. Aquí un ejemplo sencillo — una calculadora en HTML puro que puedes abrir directo en el navegador, sin servidor:
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>Calculadora</title>
<style>
body { font-family: sans-serif; display: flex; justify-content: center; padding: 40px; }
.calc { border: 1px solid #ccc; padding: 20px; border-radius: 8px; width: 200px; }
input { width: 100%; margin-bottom: 10px; font-size: 1.2em; text-align: right; }
button { width: 22%; margin: 2px; padding: 8px; font-size: 1em; cursor: pointer; }
.wide { width: 47%; }
</style>
</head>
<body>
<div class="calc">
<input type="text" id="pantalla" readonly>
<div>
<button onclick="tecla('7')">7</button>
<button onclick="tecla('8')">8</button>
<button onclick="tecla('9')">9</button>
<button onclick="tecla('/')">÷</button>
<button onclick="tecla('4')">4</button>
<button onclick="tecla('5')">5</button>
<button onclick="tecla('6')">6</button>
<button onclick="tecla('*')">×</button>
<button onclick="tecla('1')">1</button>
<button onclick="tecla('2')">2</button>
<button onclick="tecla('3')">3</button>
<button onclick="tecla('-')">−</button>
<button onclick="tecla('0')">0</button>
<button onclick="tecla('.')">.</button>
<button onclick="tecla('+')">+</button>
<button onclick="limpiar()">C</button>
<button class="wide" onclick="calcular()">=</button>
<button class="wide" onclick="borrar()">⌫</button>
</div>
</div>
<script>
const pantalla = document.getElementById('pantalla');
function tecla(val) {
pantalla.value += val;
}
function calcular() {
try {
pantalla.value = eval(pantalla.value);
} catch {
pantalla.value = 'Error';
}
}
function limpiar() { pantalla.value = ''; }
function borrar() { pantalla.value = pantalla.value.slice(0, -1); }
</script>
</body>
</html>
Guarda esto como calculadora.html y ábrelo en cualquier navegador — no necesita servidor ni dependencias. Es un buen punto de partida para aprender HTML,
CSS y JavaScript.
> it’s clearly not the case that these things only make use of Spanish training data when you prompt them in Spanish.
It’s not! And I’ve never said that.
Anyways, I’m not even sure what we are arguing about, as it’s 100% fact that SOTA models perform better in English, the only interesting question here how much better, is it negligible or actually makes a difference in real world use-cases.
It’s negligible as far as I can tell. If the LLM can “speak” the language well then you can prompt it in that language and get more or less the same results as in English.
Mac has about 15% of the market share in the US. It's not really a niche.
$3500 is more than I would spend on a hobby too, but there are, in absolute terms, a large number of Americans who can spend this much on their hobbies.
This really depends a lot on your level of expertise in a given domain and how much relevant training data the LLM has. I find that LLMs are often better than me at avoiding common React gotchas. This isn't really surprising, given that I write React code once in a while and the LLM has been trained on vast amounts of React code. This doesn't mean that I'm bad at programming. If I was writing lots of React code every week, I'd probably get better at it than the LLM.
The premise of the connector is that it attaches to the board in a similar way as soldering the chips (the LPCAMM connection interface is directly on the back of the chips) but uses compression instead of solder to make the electrical connection, so the traces are basically the same length but the modules can be replaced without soldering. There is no reason you couldn't use two modules to get a 256-bit memory bus. It sounds like AMD designed Strix Halo to assume soldered memory and then when Framework asked if it could use CAMM2 with no modifications to the chip, the answer was yes but not at the full speed of the CAMM2 spec.
CAMM2 supports LPDDR5X-9600, which is the same speed Apple uses in the newest machines:
The Max chips have a 512-bit memory bus. That's the one where the comment you linked suggests putting one module on each side of the chip as being fine, and there is no M4 Ultra or M5 Ultra so they could be using LPCAMM2 for their entire current lineup. The M3 Ultra had a 1024-bit memory bus, which is a little nuts, but it's also a desktop-only chip and then you don't have to be fighting with the trace lengths for LPDDR5 because you could just use ordinary DDR5 RDIMMs.
> but uses compression instead of solder to make the electrical connection
This is still going to have higher parasitic resistance and capacitance than a soldered connection. That's why it's not just a drop-in replacement for soldered RAM. You'd either have to use more power or run the RAM slower.
> one module on each side of the chip as being fine.
It's fine if you've got space to spare. It's not very practical for a laptop form factor.
>but it's also a desktop-only chip and then you don't have to be fighting with the trace lengths for LPDDR5 because you could just use ordinary DDR5 DIMMs.
Given how few desktops Apple sells compared to laptops, I seriously doubt that they'd want to use a completely different memory configuration just for their desktop systems.
> This is still going to have higher parasitic resistance and capacitance than a soldered connection. That's why it's not just a drop-in replacement for soldered RAM. You'd either have to use more power or run the RAM slower.
This isn't accurate. A compression interface can have the same resistance as a soldered connection.
There is a small infelicity with DDR5 because the DDR5 spec was finalized before the CAMM2 spec and the routing on the chips isn't optimal for it, so for DDR5 CAMM2 requires slightly tighter tolerances to hit 9600 MT/s, which is presumably the trouble they ran into with Strix Halo, but even then it can do it if you design for it from the beginning, and they've fixed it for DDR6.
> It's fine if you've got space to spare. It's not very practical for a laptop form factor.
The modules take up approximately the same amount of space on the board as the chips themselves. It's just a different way of attaching them to it.
> Given how few desktops Apple sells compared to laptops, I seriously doubt that they'd want to use a completely different memory configuration just for their desktop systems.
DDR5 and LPDDR5 are nearly identical, the primary difference is that LPDDR5 has tighter tolerances to allow it to run at the same speeds at a lower voltage/power consumption. When you already have the design that meets the tighter tolerances, relaxing them in the system where you're not worried about 2 watts of battery consumption is making your life easier instead of harder.
>This isn't accurate. A compression interface can have the same resistance as a soldered connection.
All the information I can find suggests that CAMM2 will have higher parasitic resistance and capacitance than a soldered connection. Do you have a source for this claim?
The issue isn't just reaching a certain speed, but doing it at the same power consumption.
>The modules take up approximately the same amount of space on the board as the chips themselves.
They do take up more space, as anyone can easily check. Modern laptop motherboards can be very small, so this is significant.
>DDR5 and LPDDR5 are nearly identical [...]
What I mean is that Apple isn't going to want to invest any resources in adding the option of external RAM just for the relatively tiny desktop market. It's not that it's technically difficult; it just doesn't make sense from a logistical point of view.
I do not think so. The Windows - OS/2 war was a big fight that Microsoft won on merits. Windows 95 was revolutionary at the time, folks queued at the malls on the release day to get it, bugs and all.
They fought the compiler wars with real engineering, giving Borland a run for the money. Different people have different opinions about Visual Studio. As a Linux user since 0.9 I did not like its architecture and focus on GUI at the expense of everything else, but I still saw it as a consistent framework done by excellent engineers. And so on.
On the desktop, I don't believe Microsoft has had significant competition for quite some time, likely back to Windows 95. In the server space, NT fought really hard against the UNIX giants of the time.
I think you might be missing the ‘concerning’ part. Which specific cases are concerning? I don’t find it inherently concerning that people can’t escape justice by crossing the Hungarian border, Bonnie and Clyde style.
Too explicitly spell it out, op is saying here that if any one of the 27 countries in the EU decides you are breaking one of their laws, they can have 1 of the other 26 enforce an EIO.
EIOs are subject to a dual criminality requirement. So it’s not as if arbitrary Hungarian laws can be applied in France via EIOs. And of course, we all know this is not happening, which is why we get radio silence from the people who are ‘concerned’ about this whenever specifics are requested.
Annex D is a list of things that are crimes pretty much everywhere.
Not sure what to make of the claim that Hungary might theoretically be enforcing Hungarian law in France. It seems surprising that no-one has noticed any specific consequences of this that you can point to.
The EIO is mostly just a formalization and standardization of a bunch of ad-hoc processes that were already in place. Law enforcement agencies in different European countries do try to assist each other, on the whole.
What you're missing is the erosion of the ability of the executing states to say things like "hey this is sketchy, we think this crime might not have happened", "hey the police department in this particular city is notoriously untrustworthy", or "hey this prosecutor is widely known in the local press to be corrupt and owns a collection of ferraris".
Now foreign authorities are trusted by default and significant parts of their reasoning are not subject to review, that's bad.
You understand that these aren't typically public, right? There's not any particularly good mechanism to discover abuse in this system in the first place, because the checks and balances are largely left to the requesting state.
>Where are search warrants issued via public proceedings? You could make the same point about any jurisdiction.
It's different though, typically you can fight those warrants after the fact, with EIOs you have to do the fighting in a jurisdiction you don't live in.
This is all deeply problematic because things like "probable cause" have very different meanings in different EU countries, even if on paper it's all supposed to be the same.
>Also, account first created in 2021, coincidentally starts posting right after the other account in this thread is replaced with a green account?
Maybe stick to one account? It’s confusing for the rest of us, if nothing else.
You are determined not to point to any specific examples and you keep switching to different abstract arguments. For example, you’ve now dropped the point about EIOs being non-public in some sort of allegedly sinister way, and are raising a different set of equally irrelevant abstract points.
>you’ve now dropped the point about EIOs being non-public in some sort of allegedly sinister way
Nonsense, I told you that EIOs are non-public after you repeatedly insisted on examples of them being abused. I did not suggest that there's anything sinister about them being non-public. The sinister part is outsourcing warrants to other countries. I can't trust that the French legal system will protect me in France anymore because now I also have to trust the Hungarian legal system, that's bad.
Frankly, it seems silly to debate about whether or not these systems are being abused when we know that Poland has historically issued one third of all EAWs.
Oh no, that's totally up to you. If you're happy with the courts in your country not being able to review the requests sent from Hungary, that's cool. Without transparent judicial review, how could we even know if the cases are concerning?
"Subject to review" means little more than "is the form filled correctly?", it certainly does not mean second-guessing by the courts in the executing state.
Like, yeah, your EIO will be rejected if you don't tick any of the crime-category boxes in the form.
I've never really understood how version pinning is meant to work with devenv.sh or Nix more generally. If I whack a .tool-versions file in my repo, everyone who works on it can use install the exact same versions of the relevant tools using asdf. That's low tech and imperfect (and certainly not a replacement for all of Nix's features), but it works as far as it goes. None of the examples on the devenv.sh page demonstrate pinning of tools/packages to specific versions.
As best I can tell, Nix enthusiasts think that this is an XY problem and that I shouldn't want to pin individual tools/packages to arbitrary versions. But the thing is that I am a rude barbarian who very much does want to do this, however philosophically misguided it might be.
If you use the flake system (which is technically still experimental, but everyone is already using it anyway), all your flake 'inputs' are automatically pinned in a flake.lock file that can be committed to git for reproducibility. So if you add nixpkgs as a flake input, your nix expressions will always be referring to the same exact package versions until you update the lock file.
The downside is that flake inputs refer to other flakes, not individual packages, so if you update the nixpkgs input it will upgrade all of your packages at once. For some packages such as Python, nixpkgs tracks multiple major versions so you can loosely pin to that version. You can also include nixpkgs as an input multiple times under different git tags/commits and only use that input for some of your packages to effectively pin them. You could keep using one nixpkgs but override the package's source to build it for a specific version/commit, but this setup could break in the future, because the derivation (and therefore build instructions) will keep evolving while your package's version will not. Or, if you really wanted to, you could straight up just copy the derivation from nixpkgs into your local repository and use that instead.
Nix is quite flexible so there's more options than just these, it just takes a little getting used to to find out what's possible. I don't use devenv myself, but some quick googling reveals it works just fine with flakes, so I would try that to see if it suits your needs.
If you care about the _exact version you are pinning_ (even though you will guarantee the pin between team members without needing to do this step), you can either pin nixpkgs repo to the state that had that version, source the target version directly, or for some ecosystems (eg ruby) you can just specify a version with a number and it has tooling to resolve that using "traditional" approaches.
In general though when working on a team, you dont really care about the _exact semver version_, you care about the major and handle version bumps by bumping the pin of nix packages.
It does, but its implicit (and so may not be the exact patch version you have in mind). See my other comment for how to handle if you _do actually care_ about pinning to a specific version explicitly.
Doesn't that pin me to a particular versions of nixpkgs? That's fine if I only care about nodejs, but if I want to maintain particular versions of different tools, it won't work.
Again, generally in other systems the full semver pinning is more of a crutch to get some 'reproducibility' that nix gives you out of the box at a much higher level. So, in general, people just pin to the major version in nix. But if you _really_ want the full semver pinning there are multiple options that I lay out in the other post. You can even patch the _actual nodejs source itself_ in reproducible/version-pinned ways.
I do want exact version pinning of individual packages. (As I said in my initial post, I’m aware that Nix advocates think that I shouldn’t want this.)
I’m not sure what other post you’re referring to. There’s one where you describe some approaches in broad terms, but as far as what the relevant devenv.sh config would look like, I’m none the wiser.
You still are pinning to exact versions of packages (and in fact are pinning to specific shas / content hashes of the packages) but you are doing so implicitly by going this "path of least resistance". The only thing that will change what _exact sha_ you are pointed at is an explicit update by someone. There is no risk of someone running install on one box and someone running it on another and them getting different _exact versions_ (or likewise, in CI it also will be the exact same). And in general thats what people are trying to achieve on teams by pinning to full semver. So thats what I mean by its generally not needed on nix.
However, to actually address your question it would be something like this (with ruby also added for comparison of whats possible depending on the language ecosystem you are using)
Pinning by version number isn’t a crutch; it’s more a question of mental models. Most people find it more intuitive to identify a world by describing the things in it than to fix the states of the things by identifying the world where they have those states. Nix sometimes feels as if someone read Kripke and missed the passage about possible worlds being a figure of speech.
In other words, many of us don’t think that version numbers are a crutch to be used in the absence of a totalizing hash of the entire state of the universe. We actually think that version numbers are, for many practical purposes, better than that.
I dont mean to imply its a crutch. Im merely pointing out that even though people say they want to "pin to a specific version", there are usually two different motivations:
- one group of people who want guarantees that what they install on their machine matches on their colleague/CI/prod machines. For this group, the nix happy path basically serves all their needs really well. It can capture nearly any sort of software dependency they have regardless of ecosystem and it pins to actual content hashes in most cases. They only care that the high level versioning is met, because again its reproducibility that they care about
- one group of people want guarantees of specific software versions. Nix still handles this, but its "more work" because nix is by default a snapshot of the entire world, of which your target software is only a slice of. And most nix snapshots of the world are "what were the most recent versions of each software package at this point in time". So you generally need to compose together multiple snapshots of the world. It works fine, its just more work (and more disk space).
In practice, again, I think most teams are served better by being in group one, but dipping into group two when they either need an "unreleased" version for software they depend on or when they need an older/unsupported version of software they depend on (or a nix release breaks their workflow). Then nix shines by being able to mix and match between different snapshots in composable/reproducible ways.
The way to do it is to find the `nixpkgs` version which contains the version of the tool you care about. There's a web site[1] that makes this pretty easy, and it's of course also doable by looking at the Git history for the program's derivation.
Then you create a named input using that nixpkgs version: either add it as a channel, import it with fetchTarball in a derivation, or add it as an input in your flake, depending on what you're doing. Then you use that named nixpkgs (or other input in the flake case) for that version of the package.
Edit: One issue with depending on things like git tags or semver versions is that sometimes people re-use versions or edit tags. Using the actual git commit hashes of the package's derivation avoids this potential ambiguity. This is why we can't have nice things.
reply