* The Runtime API is also a black box - it's just differently shaped.
* CUDA runtime APIs are also incompatible with CUDA drivers which are significantly older. Although TBH I have not checked that compatibility range recently.
* C++ is a compiled language. So, yes, in some cases, you need to recompile. But - less than your might think. Specifically, the driver API headers use macros to direct your API function names to versioned names. For example:
#define cuStreamGetCaptureInfo __CUDA_API_PTSZ(cuStreamGetCaptureInfo_v3)
and this versioned function will typically be available also when the signature changes to v4 (in this example, it seems two versions backwards are available in CUDA 13.0).
* ... meaning also that you don't have to "follow the driver release cadence exactly". But even if you want to follow it - there's a change every couple of years: a major CUDA version is released, and instead of functionality getting added, the API changes. And as for actual under-the-hoold behavior while observing the same API - that can change whether you're using the driver or the runtime API.
* Finally, if you want something more stable, more portable, that doesn't change frequently - OpenCL can also be considered rather than CUDA.
I'm only superficially familiar with these, but curious. Your comment above mentioned the VL model. Isn't that a different model or is there an a3b with vision? Would it be better to have both if I'd like vision or does the vision model have the same abilities as the text models?
The fixed allowance is the same within the EU. It's not "no roaming charges", but it is that you must not be charged for occasional fair-use roaming (which is quite a lot of roaming). They can still ban you from roaming if you are living in a different country from your contract provider - you're not allowed to buy a contract in Slovakia and then move to Denmark.
I don't think many adults remember what it was like being 13-16 years old. Twitch is part of the culture. Would I have liked to been "banned" from using IRC, chatrooms or keeping an online diary in the 90s, as were common in geekier teen culture? Not every kid is geared towards playing team sports, chess club, or hiking all weekend.
The term "online social interaction" keeps getting thrown around as if that's inherently a bad thing. For some teens, that's one of their biggest social outlets outside of school, and that is not necessarily bad even if sometimes bad things happen online.
This was a rant at best for the sake of ranting, if not for some more insidious ends. What's the point made here? Abandon Firefox because it's market share is 2%?
"I can finally say I'm Firefox-free."? Like if Firefox is the plague or something.
"Just What Went Wrong?": You went wrong, dear TFA author. Choosing hype over substance? Too desparate to meet your hackaday post quota? Who knows.
Let me anecdotally recap the state of Firefox as of 2025:
- Handles 100s of open tabs with no sweat.
- Allows ad blockers.
- Firefox tab sync. Send a tab from my phone to my desktop. See my laptop's open tabs from my desktop.
- PiP videos. Keep a video playing without obstructing you from other tasks.
- Tab containers cleanly separating work and private sessions.
- Free.
Yes, there are things to be desired from the Mozilla Foundation management end. Yes, at some point (optional) integrations were shoehorned into the browser. Yes, newer browsers may offer a friendlier out-of-the-box experience for the average user (e.g. Brave has ad blocking built-in). But all-in-all, Firefox is a fantastic browser and a real workhorse. For free.
And to be fair, the dip in Firefox popularity around 2010-2015 was deserved. The experience kind of sucked at the time, compared to the rising Chrome. Also the decision to drop XUL was in retrospect the technically correct choice. It was the main reason that Firefox managed to catch up in terms of speed and security with Chrome. Unfortunately, the change was not reflected back to the browser's market share.
I am still puzzled by how you can be a human being in this world and not be impressed by people.
The more we study AI, the more we discover one fundamental truth above an the others: people are really, really, really, really impressive.
A human being still absolutely melts an LLM like a Salvador Dali clock if the challenge is to innovate. In the race between human potential and LLM potential it isn't even close. Not a little close. Not remotely close. About as close as we are to each other compared to how close we count are to the sun.
And yet somehow there's always some fucking moron who apparently never considered this for a fraction of a second and runs around screaming that a fucking program will replace a fucking person
I dont think so. You cant train away a compression artifact that comes from the model's core architecture, LoRAs can smooth or hide artifacts, but some detail will be inevitably lost. You can try to hide artifacts but not remove them without retraining the whole model on RAW sensor data.
The argument you will hear from Americans and Europeans is that in order for it to be a "democracy" that anybody has to be able to vote. This is, of course, hypocritical because not a single one of those countries allows everyone to vote. And, just like China, every one of those countries has powerful government officials that are appointed by other government officials rather than elected by the public. And in many of them there is a parliamentary system where the public does not get to vote on the head of state, but rather the head of state is elected by the parliament.
For anyone interested in this kind of stuff with a music oriented gist, a while ago I found this awesome YouTube channel: https://www.youtube.com/@MoritzKlein0/
It makes no sense to use a protocol where the source is the one responsible for taking care of retransmission when the network spans accross minutes/hours of delay.
> Also quite puzzling is how the Air India disaster still does not have a root cause analysis done
Nothing puzzling. Straight-up cover-up.
Now, the interesting part would be to know what is being covered-up. Pilot error? Pilot suicide? Or a critical system malfunction Boeing cannot afford?
> And who really cares about bloat anyway? Hardware is super cheap nowadays.
That told me all i need to know. When you work on missing critical software bloat is usually THE killer in disguise. And its really hard to get rid of after a certain point.
> So why not use a framework that enables you to be (in your terms) 100x more productive?
Because i can be just as productive, and even more so by vetting, and choosing my dependencies with some hindsight. I dont cowboy pick some hype of the day thing, i take a real close look at the code and want to actually understand whats happening.
> On top of that, you’re arguing about languages and frameworks you’re not even familiar with.
I am indeed familiar with the PHP ecosystem, been there and done that.
I think bad regulation and over-regulation are different words for the same thing, but calling it over-regulation pushes a certain agenda that all regulations are bad, which people who profit from deregulation would like you to think.
This is such a tired HN cliche response and it comes up as a negative whenever people mention things that actually improve users privacy, even ad blockers.
It honestly boils down to this:
If some website is breaking GDPR regulations, sure, you might get somehow fingerprinted.
But for websites actually following the law, DNT is effective at best, ignored at worst. Because fingerprinting is also fricking PII. And why are you using those websites anyway?
Sure: saying "people might fingerprint you" is technically correct. But virtually everything else in your browser, from the size in pixels of your browser tab to your IP address can be used for fingerprinting by malicious actors.
So yeah, if you have to use TOR (which actually has actual anti-fingerprinting measures), go ahead and remove the DNT bit. If you don't need TOR, get an ad-blocker ASAP.
> There’s an old electronics joke that if you want to build an oscillator, you should try building an amplifier
It's funny, I was just thinking this morning about an old article in (I think) Television magazine that I read in the 80s when I was getting into electronics. The author was talking about some service notes he'd received for a particular model of Philips radio, which had just come out, and it was when shops tended to have their own service department that would repair things right there in the shop - and also, apply any "factory fixes".
One such fix was described as "Fix VIUPS", and involved changing a couple of resistors and adding a couple of capacitors. Not really any difference, but the author did think it seemed to make the amp a bit more stable and less inclined to make squealy ploppy noises at high volume when the battery was low. But, curiosity got the better of him, so he rang the Philips rep - what's this "VIUPS"?
No idea. But I'll get hold of someone at head office you can ring. Okay, what's this "VIUPS" thing? No idea, said the head office guy, but I can put you in touch with one of the factory engineers in Eindhoven.
So, a call came in, an international call! Quite a big deal in the 80s. "What's this VIUPS Fix thing in the service notes?" he asked the guy.
"Aha yes", he said in a heavy Dutch accent, "the VIUPS is the noise the set makes when the fault is present."
In physics it is common to work explicitily with the components in a base (see tensors in relativity or representation theory), but it's also very important to understand how your quantities transform between different basis. It's a trade-off.
> I find that WASM has a beautifully readable spec. One of its best features!
Disclaimer: I'm one of the guys whose face is advertising this book, as someone who bought the early access version and loved it enough to help a bit with proofreading.
I'm a self-taught programmer who essentially started from the lowest level with Z80 assembly on the TI-83+. I just wanted to know how to fit the bytes together directly without dealing with the rest of the toolchain.
I've tried reading the spec multiple times and what it revealed to me is that my lack of formal training in the subject matter is really holding me back here. I feel like I can follow 90% of it, but that doesn't matter really. It's the remaining 10% I don't understand that does.
The spec is written as a reference and gives you all the pieces, but doesn't really do a great job at fitting all the pieces together.
Everyone I know who does have some relevant background to compiler writing agrees with you though. So I think that for them it's obvious how to fit the pieces together.
Speaking for myself though, this is the first book that made the bytecode "click" as a whole.
Having said that, I think this book and the spec together are the real combo to go for. The book covers the core, and understanding that foundation makes all the extensions easy to grasp from spec alone.
* The Runtime API is also a black box - it's just differently shaped.
* CUDA runtime APIs are also incompatible with CUDA drivers which are significantly older. Although TBH I have not checked that compatibility range recently.
* C++ is a compiled language. So, yes, in some cases, you need to recompile. But - less than your might think. Specifically, the driver API headers use macros to direct your API function names to versioned names. For example:
* ... meaning also that you don't have to "follow the driver release cadence exactly". But even if you want to follow it - there's a change every couple of years: a major CUDA version is released, and instead of functionality getting added, the API changes. And as for actual under-the-hoold behavior while observing the same API - that can change whether you're using the driver or the runtime API.* Finally, if you want something more stable, more portable, that doesn't change frequently - OpenCL can also be considered rather than CUDA.