I've definitely been guilty of wording my multi-line doc comments in a way that would ensure they'd flow without awkward right margins. I would have a macro in vim that would call the fmt program to reflow the comment to 79 (later 98) characters, and then would iterate on word choice until the comments looked good. Not exactly right-justified, but no very ragged edge either.
Nvidia's been pretty terrible for open source / free software. No need to quote Linus Torvalds here. They want to control what runs on their hardware. They want to you write code against their proprietary drivers and APIs, not directly against the hardware (which these days of course also contains plenty of software, but still).
Don't expect things to go differently this time around. Nvidia wants control over the software stack. Acquiring HF fits in perfectly. The play is long term.
Yes, there is no question NVIDIA wants to lock you into CUDA and their hardware. But also, they’ve consistently demonstrated the most openness when it comes to model training, datasets, and research; even before the LLM era (e.g. StyleGAN).
There’s also modelscope.cn (china’s huggingface) which is worth checking out. I would not be surprised if one day, we have to use China VPNs to download open weight models.
I'll expand on the economics somewhat. My intuition is that you can like a moat left of you in the supply chain, but dislike moats to the right of you. (I'm using left and right as I picture this horizontally drawn. It is usually called vertical integration by economists.) But free competition in your market is worst of all. Free competition right outside your moat is pretty sweet, and that's were parent is commenting on.
Nvidia probably likes that ASML is a monopolist (it's called a monopsony). The price is high and Nvidia can't scale as hard as they want to (more general: capital intensive market). This monopsony makes sure that other chip companies can't rapidly scale up and try to beat Nvidia. That there only ever was one other GPU firm (I'm prehistoric; once there were more) and they bungled it on software, is pretty sweet for Nvidia.
On the side of their customers. It would be best for Nvidia if there is free competition for the outputs generated from there GPUs. This maximizes consumer surplus and thus demand. Maximum demand for tokens, is maximal demand feeded in their monopoly. If there is a monopoly right from you, demand is curtailed, and your value is limited.
And that exactly is why you see interest from token generators for chips. Bridge that moat and gain a larger value surplus. Both NVidia and, say, China actively undercutting the token-supplier value chain is quite interesting to watch. It's like the Opium wars with us as somewhat happy customers.
In this same vein, why isn't ASML raising thousands of billions for building their own (subsidiary) chip foundries, while raising prices and starving the market (a little) for their machines.
> In this same vein, why isn't ASML raising thousands of billions for building their own (subsidiary) chip foundries, while raising prices and starving the market (a little) for their machines.
You're looking this purely through an economic lens, while in reality geopolitical factors play a huge role in what ASML can and cannot do. The US government would likely take an extremely dim view of any new external competitor popping up for their chip foundry industry (especially with all the new US plants being built or planned) and would lean heavily on their vassal/ally the Netherlands to prevent this. Unlike with China, the US has more leverage over the Netherlands[1]
The US security state and US tech giants are joined at the hip, as they have been since the beginning of Silicon Valley[1], right through the Snowden revelations through to the present day[2].
There are - see the RTX Pro 6000, which has 96 GB.
There are a few problems though, primarily, a GPU with lots of VRAM and very high bandwidth is inherently very expensive (on top of which there is also the CUDA premium); AI use cases are better served by SoCs with lower (but still high) bandwidth and more RAM.
This is not a GPU, this is a laptop SoC with CPU and integrated GPU, and knowing nvidia it will probably be even more closed than an intel CPU. You will own even less of your hardware
When last looked at it, NVIDIA was not supporting OpenCL beyond 1.0.
Also, when running OpenCL, NVIDIA hardware disables multiple DMA engines, and allows only one memory transfer at a time to prevent OpenCL running as fast as CUDA.
Did NVIDIA finally allow open source drivers to access all parts and features of the card to allow feature parity? Last time I checked they were considering a plan for planning a solution to that.
I don't think bits like the GSP firmware will ever be open-sourced, but the opportunity to write better OpenCL drivers has always existed. Some of Nvidia's other proprietary driver backends (eg. GBM, Vulkan) are also decently neglected, but mostly out of disuse rather than malice. I don't think any of these things mean you don't own the hardware.
I love your insights which enlighten my blind spots most of the time, but I didn't blame NVIDIA for OpenCL's failure. I just noted a company's choices when it comes to a competing set of libraries w.r.t. to their native ones.
Having said that, I'll try compiling a OpenCL 3.0 program in the cluster, so I can report whether NVIDIA runs this software, and if yes, how well.
Yeah, however if Intel and AMD actually delivered a working 2.0 with proper support for C++ and Fortran, maybe the OpenCL 3.0 back to 1.0 reboot would not have been needed.
Likewise SYSCL although built on top of OpenCL 3.0 primitives, is mostly Intel, which also owns CodePlay, the company that delivered the first working SYSCL compute experience, again neither AMD nor Intel (until it bought CodePlay).
While nvidia 's drivers are closed source there's enough interest in running LLM's that you are not locked in using nvidia. Strix Halo chips have been around before dgx spark came out and deliver very similar performance.
What is the support like for them? Can they be seriously considered as alternatives to Nvidia or AMD cards? I have been looking into buying a GPU, specifically the Radeon R9700 AI Pro but noticed the Intel cards too and was not sure what you make of them.
Because making new AI models is a research activity, so the group within Nvidia (or other companies) that does that activity is called a research lab, or just "lab" for short. I don't think anyone is saying that all of Nvidia is a lab (that's just shorthand I guess).
What amuses me is that “lab” is shorthand for “laboratory” and virtually no computer research happens inside a room people would typically call a lab.
It’s a little like the trend of calling developers “engineers”. There’s no actual engineering in the traditional sense but I’m sure developers think it sounds cool to call themselves that.
That’s not what I said and the snarky remark about my experience is unwarranted (I have more experience in “software engineering” than many on here have been alive)
My point was just that I just find it amusing that people call themselves engineers when the code they produce is so far removed from the level of rigour one would expect in literally any other engineering industry.
I say this as someone who also has family and friends who are actual engineers, if they built bridges and buildings to the same standards that many developers write code, then people would die.
This isn’t meant as a criticism of developers, by the way. Just an observation at the vast differences in the domains and thus the tolerance for errors in the process.
Likewise for labs. I’ve worked in AI startups and the science departments are not something one would think of when you say “laboratory”. I get why the term is used, but it’s still amusing.
I know language isn’t static. It’s something that evolves, like how a “computer” used to refer to a person rather than a thing, but that doesn’t stop me from being amused. But maybe the real issue here is I take myself less seriously than others so I have that capacity to be amused by the titles I’ve held?
Because they are mostly research departments (aka a lab) turned into a corp structure. It’s not a new phenomenon, just that until recently labs didn’t get $1T valuations so you see it more now
Well if you find that obvious (I also do) then why do you not find their motives in acquiring HF onvious or that this move would be bad for the ecosystem as a whole? Cause it's all kinda the same thing.
"The proprietary shovel seller has some excellent tutorials on how to dig gold. Nobody else has such good step by step guides. Therefore them buying a shovel-agnostic tutorials and techniques method (that has a lot of info on using other shovels effectively) is justified."
Their (not especially great, compared to Chinese ones) models being open weight doesn't even come close to outweigh the effect of CUDA & Co being proprietary and closed.
A few years ago everyone said _Open_AI is the the most open labs. How did that turn out? Lots of coy, deceiving actions till the whole company was turned into whatever rent seeking amoral borg adjacent shell of it's former past it is now.
CUDA is proprietary for a pretty understandable reason. There's no good way for Nvidia to standardize it.
They supported OpenCL when Khronos floated the idea of a GPGPU standard to manufacturers, but OEMs didn't want to design scalable hardware or sponsor the software.
Evidently we should, because Linus has been more positive about Nvidia in the last 2 years [0]. I've been using the open driver for years now, for both gaming and CUDA.
He definitely sounds more pragmatic than before, which is, in a sense, more positive.
> This is actually one of the benefits brought by AI; it has made Nvidia a good participant in the Linux kernel space. [...] Now, when Linux is so important for AI clouds, Nvidia suddenly cares very much about Linux.
Nvidia releases some of the most open open weights models, Nemotron 3, which have the full training code open, and most but not all of the training datasets.
Nvidia is a big company. They are good about some things and bad about others.
I think they really do like open weights because they make some of the best hardware for training, and the more open weights models there are, the more people are training and fine-tuning them, mostly on Nvidia hardware.
I feel like Nvidia is one of the better choices for buying Huggingface. Not perfect, but definitely far from the worst.
The worry is not that Nvidia isn’t open about their models.
The worry is that Nvidia is trying to control the way you run those models. Trying to bake CUDA assumptions into model design, and pushing the software ecosystem to be as Nvidia first as they can.
Hey. I worked there, and I'm no longer bound by their PR policy, so I can mention this. Also, know that the fact that I worked there doesn't make me privy to their high-level strategic decisions, this is a more look from the trenches kind of thing.
My impression I've developed in the years of working there is that Nvidia's relationship with opensource is... not intentional. They kinda suck at it because they genuinely don't know how to do it more than they want to make money out of it.
Here's an anecdotal "success story" which is also an illustration to how things might not work out well otherwise.
So, I was on the team that deals with server infrastructure. One day we get a new "feature" which was supposed to allow Slurm (the workload manager, a kind of software used to run "jobs", including eg. model training) to be deployed with distributed MySQL as a backend. The feature is all obviously written by a single developer with an enormous amount of "help" from AI. I was tasked with testing it.
Trying to figure out what it does... I realized that the "distributed" part of the feature was to be achieved by integrating with Oracle's MySQL by means of using MySQLShell (another proprietary Oracle's product). Until that point, by default, we integrated with MariaDB. Not only was it using Oracle's proprietary tool, the tool, actually, didn't support the "distributed" part of the "solution". It was pitched as the "first step on the way there".
So, I was able to push back on it, mentioning Galera, arguing that the "solution" doesn't solve the problem and will require from customers to change databases (even if they are mostly compatible... they never quite 100% compatible). And the misfeature was rolled back.
I made an effort to investigate how did we even get there, and turned out that whoever authored the "solution" had an experience of working with Oracle products, but never really tried the open-source ones. So, he didn't do a research. He just used what he knew.
Unfortunately, this is a rare win, where the evidence of disadvantages of using proprietary solution was huge and enough to turn the tide. But often it doesn't face any resistance because nobody is even aware of the problem.
If that's true, it may bode well for the future. The AI boom creates some strong incentives for Nvidia to develop an intentional strategy for software generally and FOSS specifically, and there's a chance that could influence the rest of the company in a very positive direction. Hopefully, what they learn by working with HF and having the value of their hardware products increasingly determined by their ability to run FOSS software stacks will backwash into the rest of the company, or at least make them much more aware of the problem at all levels.
I do think that they still might be a bit reticent to release fully open-source drivers, though, only because of the extent to which hardware design could be inferred from the driver source. OTOH, AI itself is making disassembling and reverse engineering binary code easier and easier, so there might not be much of a point to withholding the source in the near future.
> as a force to have open weight models run better on Nvidia against the rest.
this is the crux - if nvidia makes it so that open weights end up running better on nvidia hardware than competitor's, then it's going to prevent hardware innovation and competitiveness in the entire sector.
It's like as tho General Motors buys out oil refinery to make gas for all, but the gas somehow runs smoother in GM cars.
If you don't own the customer relationship, you don't own the profit. See App store, FB.
NVidia is delivering commodity hardware to the hyperscalers, and would eventually get commodity margins (when hyperscalers make their models work on their own hardware).
Amazing article on relevant economics of squeezing vendors - actually about antitrust ad-models but:
The answer is that [advertising based] companies are an ideal test case for an increasingly common business meta-model, where companies try to create a consumer surplus at one end in order to maximize their negotiating leverage for capturing the producer surplus everywhere else in their supply chain.
It's a clever move if that's what they're doing. They're restricted in China, and are likely to face stiff competition from Chinese chipmakers in the coming years. Acquiring the largest repository of trainable models and ensuring they run better on Nvidia hardware is probably one of the few moves they have for keeping ahead of the competition. I mean, it would be terrible for the consumer, but it does make me think that NVDA is a decent investment.
Well now that they own it, they can do whatever they like. They don't necessarily have to be optimizing the models for their hardware, they could just setup preferential pipelines to funnel users to their ecosystem. That seems fairly prudent given the challenges coming their way.
We can stop with these weak excuses since AMD and Intel have done more for open source than Nvidia has, including their GPU drivers for Linux.
Nvidia on the other hand has not and the best they have done is a bunch of closed-source blobs which they do more closed source releases than the rest.
Mojo is open source and targets all GPU architectures for their compiler regardless of the vendor and nvcc targets their own (and both that and CUDA are closed source).
So this is directly an apples to apples comparison.
I'll give credit to Intel, they've always been open source friendly and I prefer to buy them because I'm not a gamer, so don't need the best.
AMD is another story. Their binary closed source blobs were even worse than nvidias for many years. So much so people used terrible performance open source tries just to avoid the headache. That they finally slopped together an open source version after they'd lost the GPU race isn't exactly noble. But as an open source supporter in general, I commend the effort still.
I care, I just don't believe you in that statement. There were "confidential nda" notes embedded in the release that Chris didn't remove until afterwards. That doesn't scream: "we're going to open source this some day!"
If it was going to "eventually" be made open source, why not do it from the start? Why not do it a year in?
From what I was told, your speculation is incorrect. I can't say anything more than that, sorry.
I don't know why you're so aggressive in tone towards me, chill out.
> If it was going to "eventually" be made open source, why not do it from the start? Why not do it a year in?
That isn't how open sourcing software works. It gets released when it is ready or gradually.
But of course as I predicted that you would ask that question. Why didn't Linus release Linux immediately? Why did he wait 29 days to do it instead of the day when he announced it? Why didn't Rust release 4 years early as soon as is was eventually open sourced?
> From what I was told, your speculation is incorrect. I can't say anything more than that, sorry.
Who told you? Nvidia directly?
The correct answer is that you do NOT know the reason yourself because there was NO discussion at all.
It took about a week to get Sun Microsystems to open source Tomcat and Ant, which became massively distributed and used software. So yea... it happens quickly.
I'm going to skip past all of your asinine aggressive response and just answer one thing again since you missed it the first time...
> It took about a week to get Sun Microsystems to open source Tomcat and Ant, which became massively distributed and used software.
So that was not even open sourced “from the start” either.
You understand that you just undermined your own point? It was released when it was ready, rather than from the start.
The entire point is one company gave a gradual open source release over several months to a year, verses another company that has open sourced close to nothing related around CUDA or nvcc for decades.
nvcc remains completely closed source despite it even using Lattner’s LLVM (which he open sourced) as a dependency! (shocker)
> I'm going to skip past…
Exactly. Skip it because you seem to be struggling to answer those basic questions.
Nothing was missed as I already responded to your last sentence by asking you to post exactly what Nvidia just told you verbatim since you claimed to know the true reason. You failed to answer.
If that is too difficult then a paraphrasing is far better than: “I can’t for just reasons.”
Or just be honest and say: “I do not know the reason”.
> It was released when it was ready, rather than from the start.
Nope. It was released when they realized we were building something that was going to be competitive with theirs. It was viewed as better to join forces than do it separately because we were already helping them design the servlet spec.
> you seem to be struggling to answer those basic questions
I have yet to see a question, just a bunch of ad hominem. You really have some weird personal beef with me. Seek help and support for your anger issues.
The rest of the details to this are irrelevant. We already know that it was not open-sourced 'from the start' and as you just admitted, it took a week to get it ready and transition it from closed to open source.
So even with your example, it fails your own qualification for a project to "eventually" be made open source.
> I have yet to see a question, just a bunch of ad hominem. You really have some weird personal beef with me. Seek help and support for your anger issues.
I don't think you even know what an 'ad hominem" is or even realize that you just did one in your own comment as a distraction for not answering a basic question. But I'll remind you about what that question was since you missed it:
"Who told you? Nvidia directly?"
These are very basic question(s) that you are really struggling to answer. In this entire thread, you could not even give the real reason why Nvidia never would open source their CUDA or nvcc software when you "claimed" to know.
So again, Repeat exactly what Nvidia told you right here, given you claim to know the "true" reason or just say "I don't know".
> I answered your question. "you ever ask Nvidia why? i did."
No you did not. You are referring to a question that I already answered for you [0]. Your answer was incorrect.
>> The correct answer to my question is "No". CUDA or NVCC was never open sourced during its lifetime.
> The only struggle is your understanding. Maybe english isn't your first language, but that is me saying I asked Nvidia.
Says the person that does not know what an "ad hominem" was nor did you even realize you just did one in a previous reply. The question I am basically asking you is to elaborate on what the true reason was since you claimed to have asked them (Nvidia).
If Nvidia gave you their response, It should be very easy to just say it right here word-for-word or paraphrase what they told you then. Many replies later still, you are struggling to even do that.
Such as basic question to answer and yet you continue pretending to know the reason when you clearly don't know.
I don't have to elaborate on it, nor would I as the matter of the discussion was confidential. If you want to ask them and get the answer, go right ahead.
As a AMD GPU user, I feel as if trying to mandate CUDA only or some other way to increase NVIDIA lock in like that would be met with people leaving the platform or at lest simply working on the non NVIDIA formats away from hugging face. Though requiring a lot of space it's quite easy to spin up a competitor at least for hosting weights. And if they try some legal shenanigans then many countries outside the US will still be happy to host I am sure why not China?
The only thing I can see them being able to get away with is increasingly bending the hugging face python API and any other features of that sort they develop to NVIDIA only. I personally don't use that and don't see a reason to and I am not sure how many people do use the hugging face python library.
Hf’s python / transformers is a hot mess. It conflates so many different ideas into huge monoliths that it’s barely usable for anything other than the small snippets listed for trying out models.
They need to take a machete to all the cross coupling they’ve metastasized.
> Nvidia's been pretty terrible for open source / free software.
Their strategy for AI is pretty clear and they bank on on-premises OSS models for the busines, with their really cool open-source software:
https://www.youtube.com/watch?v=tmcn1-jFLWY
This is a really good watch and is a glimpse into what the actual future shapes up to be considering the current situation in where the OSS Chinese models successfully compete with proprietary US ones.
Arguably, this move will help AI open source market more. Nvidia has an incentive to make AI open source competitive with closed source. If OpenAI or Anthropic gains in market share, they will eventually gain power over hardware vendors as well, which Nvidia does not want.
Nvidia wants people and companies to go choose a free open model, run that model on Nvidia hardware. And because Nvidia can't fully control what hardware an AI model can run, Apple Silicon and AMD hardware users will benefit as well.
I think this is part of an open-source play. I'm not arguing your other points, I think they're true.
They're trying to mix up the competitive landscape(that doesn't impact their bottom line, and I don't think opensource is eating their lunch), so I don't think this is fake, at least that's my initial take.
I am not sure you need to posit nefarious intent for this to be a bad deal for the industry at large. Basically the only provider of GPUs getting into vertical integration is a classic monopoly move and I hope regulators look very hard at this.
"That's not how citations work." (Dude on the interwebz, 2026)
But more seriously, this is my first time seeing that as well, and I'm not sure I like it. Citing an LLM is a little like citing Wikipedia to me, you cite the primary source the LLM is quoting directly, not the secondary source.
Far worse from my perspective is that it's not a fixed citation that it's not falsifiable. It's just a mutable, generalized source, which is stochastic in nature.
It’s the formatting and formality that bother me. Say “I looked it up with Gemini,” don’t give me some weak attempt at “proper citation” to legitimize the bare minimum effort you put in.
So much of present day feels like being back in middle school around the turn of the millenium, with classmates (and even some teachers!) new to the internet insisting that "source: internet" or "source: google" was totally fine.
They’re buying a brand, some employees, and some momentum — not any of their software. HF probably does have propriety goodies to make it all run efficiently, but certainly not a billion dollars worth, much less 13!
We are so used to these numbers being thrown around in the AI era that something one needs a reminder that this is 13 billion, not million. Insane exit by HF.
Was looking for this comment, the tech world has gotten completely insane with ”valuations”. I would love to hear why it was 13 and not 5. It would still be completely insane at 5 billion, but someone though they should add another 8…
Opportunity cost for Nvidia to prevent HF from going public or being sold to someone else. It's an insight into Nvidia's market prediction and what HF told them they'd do if left alone.
No company is going to be acquired for their software alone with multi-billion valuations ever again. It should be clear by now that code alone is not where the value is anymore, if it ever was.
Signed integer addition is only associative when overflow is defined to wrap around like unsigned arithmetic. This condition is matched here, because only debug builds panic on overflow. However, it's a bit of a gray area that the article completely ignores.
> Rust's signed arithmetic is fully specified to wrap around.
Well, kind of. It's currently documented to wrap in release mode by default, but it's just that - a default. You're free to enable overflow checks in release mode (or disable them in debug if you really like oddball configurations), and either way overflow is considered a logic error that devs shouldn't rely on (and basically can't rely on when not in control of the end binary since it's the end user who controls overflow checks).
The Rust devs are theoretically open to making signed overflow panic by default, but consider such a change unlikely unless "something materially changes" [0].
Thanks for clarification, it seems Rust devs (as opposite to C devs) like good defaults and don't like making code accidentally cut yourself just because you looked at it wrong
This deserves elaborating on, because it's pretty cool.
Rust has two behaviours around overflow. In debug builds, it panics, in release builds it wraps.
IMO wrapping is a reasonable-enough behaviour to avoid UB in release builds, and panicking in debug is definitely the correct behaviour, because you're only avoiding UB by defaulting to something, but that's not nearly enough. In most applications where overflow is a risk you should make sure to choose what behaviour you consider correct.
Thankfully Rust has a pretty robust story around this:
fn add_behaviour() {
let small: i32 = 123;
let big: i32 = i32::MAX;
assert_eq!(small.wrapping_add(big), i32::MIN + 122);
assert_eq!(small.overflowing_add(big), (i32::MIN + 122, true));
assert_eq!(small.overflowing_add(small), (246, false));
assert_eq!(small.saturating_add(big), i32::MAX);
assert_panics!(a.strict_add(b)); // (nb: Not a real assertion)
}
And you could easily implement the default behaviour yourself with conditional compilation:
No. If you want wrapping, ask for it with Wrapping<T> or the specific Wrapping types, or the wrapping arithmetic APIs
It's true that since it's safe and faster, release builds default to wrapping rather than panic, but it's still wrong if you overflow any of Rust's default integer types, it's just that in a safe language it won't be Undefined Behaviour.
"I can't be bothered to do it correctly" speaks to the quality of the rest of the product, it's a Brown M&M [read about the Van Halen test if you don't know what a Brown M&M means]
Probably never. This has been debated to death by both C and C++ standards committees. The consensus is that, since signed overflow is almost always a sign of a bug in the program, keeping it undefined enables compilers to optimize by assuming it never happens, and also allows sanitizers to continue to flag it to developers so that they fix their bugs (though it could be argued that, a sanitizer doesn't really have to strictly adhere to the standard, the committee apparently didn't feel that way).
> and also allows sanitizers to continue to flag it to developers so that they fix their bugs
I've never really found this argument particularly convincing; as you say, sanitizers don't have to strictly adhere to the standard, and they do in fact take advantage of this flexibility to check behaviors that "are not undefined behavior, but are often unintentional" (e.g., -fsanitize=unsigned-integer-overflow).
Makes me wonder whether "sanitizers can't flag defined behavior" is meant to be shorthand for some more nuanced position ("the false positive rate for signed overflow sanitizer checks would be too high", maybe?) or something else.
Of course, -fsanitize=unsigned-integer-overflow isn't enabled by default, and few people use it (github code search gives 6K results for that, compared to 175K for "-fsanitize=undefined"; which to be fair is a lot higher than I expected, but still not a lot).
> Makes me wonder whether "sanitizers can't flag defined behavior" is meant to be shorthand for some more nuanced position
And signed overflow checking would have to be off-by-default too, if people were allowed to start relying on it. It'd be less "false positive rate too high", more "it disallows you to use a genuine language feature that is actually useful", defeating the point of defining signed overflow in the first place.
(imo defining signed overflow specifically for reducing attack surface from exploitable UB is a mostly-separate discussion, which should not affect core language semantics, and certainly not what users would be suggested to do)
> Of course, -fsanitize=unsigned-integer-overflow isn't enabled by default, and few people use it
Sure, but it's still a counterexample for "you can't define it because it means sanitizers can't warn for it". Sanitizers can warn for it; you "just" get a worse signal-to-noise ratio.
> It'd be less "false positive rate too high", more "it disallows you to use a genuine language feature that is actually useful"
I'm not sure I see the distinction? Flagging a correct use of a language feature as incorrect is more or less the definition of a false positive, so if intentional signed overflows get a reasonable amount of use then that'd presumably result in an unacceptably noisy check to be enabled by default.
> defeating the point of defining signed overflow in the first place.
As for unsigned overflow checks I'd imagine the intent is that one would enable that particular check if you think that the corresponding overflow is more likely to be unintentional than not, and in the cases where it actually is intentional you can suppress the check.
> it's still a counterexample for "you can't define it because it means sanitizers can't warn for it"
Sure, technically you can write a sanitizer for anything. It just becomes less a "sanitizer" you can always recommend everyone everywhere use, and more of just a heuristic thing that only really works if you design your code for its arbitrary desires.
> and in the cases where it actually is intentional you can suppress the check.
imo it'd be nice to have separate types for wrapping and non-wrapping integers for that, so that you have actual language-level semantics and an easy way to mix things (e.g. wrapping arith for hashing, mixed with non-wrapping arith for loop index or whatever) instead of suppressions.
> It just becomes less a "sanitizer" you can always recommend everyone everywhere use, and more of just a heuristic thing that only really works if you design your code for its arbitrary desires.
Sure, and that's basically what I was wondering about with respect to "can't define it" being shorthand for something else
> imo it'd be nice to have separate types for wrapping and non-wrapping integers for that
I think I'd agree, though I'd imagine it's a bit late for such things to be deeply integrated into the language. At least making your own isn't horrendously difficult.
> Sure, and that's basically what I was wondering about with respect to "can't define it" being shorthand for something else
Eh, I'd say it's still the same thing; can't define a sanitizer for it if what you define isn't a sanitizer. Depends on a specific definition of "sanitizer" though.
> At least making your own isn't horrendously difficult.
In C++ perhaps, but impossible in C. (and there are still some funky edge-cases where multiplying two `uint16_t`s can overflow due to implicit promotion to signed int; C's _BitInt solves at least that)
> Depends on a specific definition of "sanitizer" though.
Hrm, I suppose a general definition would be something that you use to check for certain (unintended?) runtime behaviors? Though I also feel that could include hardened implementations and stuff like valgrind....
Making signed overflow EB would preclude using signed overflow for optimization though, which seems to be (correctly or not) considered an important use case.
I remember that EMACS meant Eight Megabytes And Constantly Swapping, a reference to the Emacs editor requiring a system with 8 MB of memory and then still swapping. It was considered an exaggeration. Even Windows 95 could run OK-ish on a system with 4 MB of memory, with 8 MB being plenty. We have gained some things in the meantime, and lost some too.
My main desktop PC has 4GB of RAM running Windows 7 with all the crap disabled. The OS uses a few hundred MB, with everything else free for software development or whatever I'm doing with it.
I don't think I could get Windows 11 to even boot in 4GB even though it does about the same as Windows 7 did.
> even though it does about the same as Windows 7 did.
That is your opinion. Did you check the number of svchost.exe instances on the two OSs ? Did you check the number of system processes.
Win 11 has telemetry, to improve it. It really cares about your security, although the bad guys are still able to install ransomware. And, the most important, Windows 11 has rounded corners and 3D acceleration for the 2D windowing system.
See ? A lot of improvements.
Now of course, you have 2 (gray) colour choices: light or dark. But this is because of astonishing advances in Computer Science.
And, last but not least, a quote from John Malkovitch: see youtube Space Force.
Yeah, I did forget that it has the visually stunning flat UI that everyone kept begging Microsoft to add. So maybe the multi-gigabyte memory size increase was worth it after all.
EMACS was indeed big and fat back in the day but hasn't grown much and is downright svelte by today's standards. Currently its using ~80MB on my system, compared to 7GB for firefox, 1GB for signal desktop (a chat app! yes I know its electron) and ~840 MB for gnome shell.
The program terminated just a few moves into the game when there were plenty of legal moves left. Also, it is surprisingly hard to play chess as a human when there is no checkered board.
The article makes it sound like the Tesla Semi is physically infeasible. Yet, it is in active use on a sufficient number of long-haul routes that ignoring this proof of existence undercuts some of the central points the post tries to make.
The combination of higher efficiency, regenerative breaking, and some regulatory wiggle-room such as slightly higher allowable gross-weight (2000 lbs in the US, and 2000 kgs in the EU), together with reduced maintenance cost and time significantly affect the economics of trucking.
As regulatory frameworks price in more externalities of internal combustion engines, such as the climate and health effects of their emissions, burning diesel will no longer make economical sense. All road transport will end up being battery-electric. The declining cost of owning and operating electric vehicles compared to internal combustion ones will reach this point even without regulatory changes, just at a slower pace.
Is regenerative breaking signifiant on long routes? I barely brake on long distance but the gas pedal is used almost uninterrupted. My naïve guess is truckers optimize even more their acceleration/beaking.
Can't help myself: whenever I see Windows 3.11, I have to compute the difference between it and Windows 3.1. So, I fire up the calculator from the Accessories folder, and compute 3.11 - 3.1. The result: 0.00. Try it! :-)
reply