4,431 karma · joined May 23, 2021
They lost a lot of goodwill back then. Some of their potential customers migrated to OpenSearch and never looked back, even after they backed down and went open-source again under AGPL.
Qualcomm has almost no products in the high-end inference/training market. The industry standard is the NVIDIA Hopper H100/H200.
What could they possibly get from acquiring Modular?
Why not just standardize it? It seems to be a better way than adding a new method.
I think a problem with open-weight models is that while you can improve them, you are not going to create the next generation of LLMs by fine-tuning. We are at the mercy of frontier labs for access to SOTA LLMs. For example, Anthropic recently started requiring identity verification for Claude [0], same for OpenAI [1].
If one day China's distillation labs stop releasing their LLMs as open-weight, I doubt American labs will continue to release free LLM weights without that competition.
That's where fully open pipelines shine: they enable the community to create the next generation of SOTA LLMs. That is the only way LLMs truly become sovereign.
Nvidia Nemotron is also an open training source model, though a portion of its dataset remains proprietary.
Quoting lambda's comment:
> Note that the Nemotron models are generally stronger than Olmo and K2 Think V2 (according to Artificial Analysis benchmarks), and there is a lot of overlap in their datasets (lots of datasets are based on the same sources with different filtering, Olmo and K2 Think V2 both have used some Nemotron datasets).
> But yeah, Nemotron is a modern and fairly capable LLM, even the 122b is more capable than Deepseek R1 (a 671b model) on most benchmarks, and there's also the recently released 550b Ultra now.
I dealt with a few instances of online ID verification recently, and in my experience, they don't close your application when your photo is not clear. They mark it as "awaiting customer response" and kindly ask you to upload again.
> The major goal Wall suggested in his initial speech was the removal of historical warts. These included the confusion surrounding sigil usage for containers, the ambiguity between the select functions, and the syntactic impact of bareword filehandles. There were many other problems that Perl programmers had discussed fixing for years, and these were explicitly addressed by Wall in his speech.
> An implication of these goals was that Perl 6 would not have backward compatibility with the existing Perl codebase. This meant that some code which was correctly interpreted by a Perl 5 compiler would not be accepted by a Perl 6 compiler. Since backward compatibility is a common goal when enhancing software, the breaking changes in Perl 6 had to be stated explicitly. The distinction between Perl 5 and Perl 6 became so large that eventually Perl 6 was renamed Raku.
https://en.wikipedia.org/wiki/Mitchell_Baker#Mozilla_Foundat...
With MV2, every request must be filtered with slow, JIT, garbage-collected JavaScript code. In MV3, filtering is handled by native browser code using the list provided by extensions. UserScripts could be used to modify the DOM, but that requires power users to manually enable it.
There is a limit on how large the list can be, depending on the browser.
A self-respecting hacker would choose a piece of tech that is well-maintained, not one that only recently added profile support after all these years, or one that still offers an ancient bookmark and history UI.
That way, the page is self-contained as it is, but requires no bundled binary code to serve the site. It is actually safer security-wise.
The vendored script can be as simple as this:
const site = {
"path-1": "<!DOCTYPE html><html> ... </html>",
"path-2": "<!DOCTYPE html><html> ... </html>",
// More paths
}
function attachListeners() {
for (const [path, html] of Object.entries(site)) {
document.querySelector(`a[href=${path}]`).onclick = () => {
document.documentElement.outerHTML = html
attachListeners()
}
}
}
document.addEventListeners("DOMContentLoaded", attachListeners)I think the misunderstanding stems from the browser's "Save As" reference in the description. It is misleading. You use "Save As" to save a single page, not an entire website.
Also, the description lacks a clear explanation of the project's purpose. It would be helpful to include a sentence explaining that the program downloads an entire website, not just a single page.
It strips out all the JavaScript too, but also packs everything into a single HTML file that is easy to transfer. Binary assets (like web fonts and images) are packed as base64 strings.
They also offer a CLI powered by Puppeteer. [1]
comm -23 <(apt-mark showmanual | sort -u) <(gzip -dc /var/log/installer/initial-status.gz | sed -n 's/^Package: //p' | sort -u)
Most Linux package managers cannot separate user-installed packages from system packages. This makes cleaning up your workstation nearly impossible and a pain in the ass, since you can't tell what should be removed, or more importantly, what can be removed.
Also, most native package managers update much slower than Homebrew, meaning you often only get outdated packages.
Most Linux package managers cannot separate user-installed packages from system packages. This makes cleaning up your workstation nearly impossible and a pain in the ass, since you can't tell what should be removed, or more importantly, what can be removed.
Also, most native package managers update much slower than Homebrew, meaning you often only get outdated packages.
OwnCloud is written in Go but employs an open-core model. Some features are locked behind a proprietary paywall.
OpenCode started as an independent CLI project. Their desktop app is still in beta, and it was never a fork of VS Code.
I believe they contain no code derived from VS Code.
As a counter example, Brave is heavily invested in C++ and Rust, and I believe they could handle that work much better.
With MV2, every request must be filtered with slow, JIT, garbage-collected JavaScript code. In MV3, filtering is handled by native browser code using the list provided by extensions. UserScripts could be used to modify the DOM, but that requires power users to manually enable it.
Their tech stack is heavily JavaScript-focused, as their entire UI is written in JavaScript.
It seems they spent so much of their budget on the CEO's salary that they couldn't afford an extension review team.
Quoting open-paren comment (2024):
> As far as I can tell, there are maybe two reviewers that are based in Europe (Romania?). The turn around time is long when I am in the US, and it has been rife with this same kind of "simple mistake" that takes 2 weeks to resolve.
Also, there are a few parts of Firefox that still look ancient, like the bookmarks and history managers, as well as the PDF viewer, where the buttons are too small to click easily. Unfortunately, those are unusable for a Gen Zer.