They still have not fixed their build system. Meson/ninja or cmake would be alternatives. Nothing to have them abandon mozconfig ... this is legacy code. The rest of the world moved on. Mozilla lives in the past.
Could not agree more. I am honestly confused by the need for more than what FF/Librewolf offers and have been actively doing frontend for a long time. Plus no hassle with uBlock. And their Focus mobile browser is nice. I have the same complaints about their leadership as most but at least I feel I have some autonomy with their browser.
> We're a niche browser that is lucky enough to get well funded.
Now - we really need a viable alternative to the Evil Google Empire. For a while I had hope that ladybird would be that competitor, but that died after I was banned from github, as well as Kling making some really strange decisions in the last year or so, with weird explanations; most recent one the "we don't need external contributors so we close that down" (in part also due to the rise of AI slop spam, which is indeed annoying, but Kling is a strange guy really). I gave up on Mozilla many years ago already, though. The key insight I had was when one mozilla dev explaind that all linux guys use systemd + pulseaudio. So, using youtube (which annoys me because the evil Google empire controls it as well), I had no audio on firefox. Chrome on the other hand played fine (I only used alsa). So, the same machine, almost the same software stack (excluding pulseaudio; I did use system back then though), means that one browser plays audio fine, the other does not. Now, I could recompile firefox and enable non-pulseaudio audio ... but look at this:
There is allegedly a python-only alternative. I tried it. It did not compile.
This is not the only issue I had. Many more problems existed with Mozilla and I also think that becoming addicted to Google money killed Mozilla. It is a dying shadow and has been for a long time. Yes, we need alternatives, but Mozilla failed us many years ago already.
I don't have a real solution against the evil Google empire. It's not even only Google; many companies are part of the evilness. I am almost beginning to sound like Richard Stallman, though I don't feed off of my feet - but the main point here is more to have real alternatives. Firefox is useable, no doubt, but it's not going to change the control Google has over the world wide web. We need something much more fundamental - control by the people. Everyone sees what Google and co are doing. Something has to change fundamentally, to stop Google parasitizing on the rest of the world. But for this you also need to have software alternatives that work.
The only thing I can come up with is to make all components of the browser/www stack as modular as possible and to also come up with alternatives. W3C also betrayed us when they demanded DRM into everything. I don't want that. Next in line will be mandatory age sniffing. This is currently ongoing. It will be extended. Systemd already added support for it; Poettering tried to do damage control but clearly failed: and reddit censoring like crazy - https://old.reddit.com/r/privacy/comments/1rzykul/the_system... as is typical.
Hey, we have the evil Microsoft empire :) Or the Apple alternative.
Maintaining a browser engine including patching the latest vulnerabilities when someone points Mythos at your code is a really hard problem, my feeling is you need a certain size of organization and funding as your table stakes.
Someone should convince the EU to look into funding a new browser, maybe.
What if the EU bought some big chunk of Mozilla, something like Mozilla EU, and then ran it? Would the US then cry out against EU buying US companies and start to fund Mozilla?
American here. We'd bitch, piss, and moan about the EU buying US companies. We wouldn't fund Firefox though, we'd be more likely to give a huge government contract to facebook to reskin chrome or some other stupid shit.
Skynet has indeed begun. There was a post recently about the very first time completely independent non-humans chose to kill humans (Russians) in the Russia-Ukraine conflict.
One of the reasons is, you don't get really good data on how something works until you start running clinical trials for it. It's all very time-consuming - having to plan how the trial is going to work, getting approval for it, finding subjects who meet the criteria (here, a specific type of cancer at a specific stage probably) and sites near them willing to work with you, manufacturing and shipping the treatments, and only then can you start gathering data. If it didn't work, you gotta start over, And it all costs a boatload of money too.
Let's see... first of all, 14 years ago was the discovery of the base mechanism, not of specific treatments. So specific treatments need to be developed, delivery systems need to be developed, side effects reduced. Then you need safety tests and efficacy tests.
> mRNA vaccines are also quite different. Do they modify the DNA? Of course not. So that's already very different.
And yet it took more than 30 years after the first mRNA experiments to develop a successful vaccine. Why it should be so much faster for CRISPR & Co?
This approach can work for some genetic diseases such as blindness based on some cells in the retina or partial blindness. For others this is not really a cure. If you want to cure people with progeria, does curing 20% of the cells really help? Perhaps 100% is not necessary, but it would seem strange to cure only some cells but not others. You'd have a mosaic of cells where some would work and others don't. Cells interact; timing also plays a role in development. I don't really see that aiming for anything but a very high number of cells cured, can work.
Lipid nanoparticles are quite old as-is. How do you target cells specifically?
> If you get really good at delivery, you can destroy A LOT of cells very quickly.
You can destroy cells quickly. Ok. So the question is: how do you detect specifically only cancer cells via lipid nanoparticles? That was already a problem years ago with Herceptin. The rationale that is always used is that "we need to do something" for certain aggressive cancers. It has never been a super-effective technique, despite all the promo of how monoclonal antibodies are so accurate.
> As you "get good" at killing the target cells, the net effect can turn bad. It will probably be a balancing act.
That's already the status quo in the whole cancer field. I don't think that more than sloppy accuracy is acceptable for any gene therapy - and the off-target cleaving of CRISPR has always been the number #1 problem here.
> I don't think that more than sloppy accuracy is acceptable for any gene therapy
Valid critiques of Cas12a2 must acknowledge the mechanistic differences between Cas9 and Cas12a2. There is no research to suggest Cas12a2 is "sloppy" and significant research that demonstrates it is not "sloppy."
I appreciate the skepticism but I would encourage you to study the actual mechanism discussed in the paper.
> So the question is: how do you detect specifically only cancer cells via lipid nanoparticles?
You don't. Healthy cells will also get these nanoparticles, but without the triggering DNA sequence, the mRNA payload will remain inert and eventually will be degraded.
> Healthy cells will also get these nanoparticles, but without the triggering DNA sequence, the mRNA payload will remain inert and eventually will be degraded.
If it were to work, gene therapy as-is would be possible. Which it is not,
not even for those overpriced therapies. I have no doubt that sooner or later
it will happen, as the problem space is finite, not infinite, but I simply
don't see the correlation here.
> The implications of Cas12a2 on undruggable conditions that exhibit known driver mutation profiles is profound.
So what does this change exactly? Humans defined it as "undruggable conditions". You can reason this is an improvement, but I still see it in failure-territory. If it were to work, gene therapy would be an accurate - and affordable - technique. Which it is not right now.
> I am a layperson in this field (I'm a SWE, not in biotech), but I am happy to answer questions.
How does "answering questions" offset the technology being inferior right now?
> So how does Cas12a2 mitigate off-target effects?
Others in this thread may be able to give a better analogy, but I'll try:
Cas9 is like open heart surgery on millions of cells all at once. We know the specific outcome we want - a surgical replacement of a sliver of a sequence - but just like open heart surgery, it's an inexact operation. Cas9 tolerates mismatches which categorically allows off-target matching. It also operates on DNA, so any off-target effects reprogram the cell's primary source code.
We want the Cas9 "patient" cell to survive.
In contrast, Cas12a2 is key-locked self-destruction switch. It targets single-stranded RNA transcripts with a specific guide protein. So the specificity is two-fold: the guide protein doesn't tolerate mismatches, and its operating on a _downstream byproduct_ of the DNA. When the key (guide protein) matches, it unleashes total destruction within the cell.
We want the Cas12a2 "patient" cell to die.
> If it were to work, gene therapy would be an accurate - and affordable - technique. Which it is not right now.
Correct on the first point. If it were to work, gene therapy could be more common. I do not know how to make it affordable, yet. In the models I've built to commercialize this I estimate a Cas12a2 treatment would cost approximately as much as a bone marrow transplant.
> How does "answering questions" offset the technology being inferior right now?
In fairness, asking and seeking answers to questions is all I have right now. There is no cure to my disease so the upside - no matter how futile you may perceive it to be - to me, is infinite.
If I can solve it I may get a few more years with my daughter. If I can't, I can show her how to live fighting for an answer that may never come.
You're not wrong, you and I just have different perspectives on the upside.
Will WebAssembly ever achieve a real breakthrough? It's been almost 10 years since it came around. HTML, CSS and JavaScript were a breakthrough back in the days. WebAssembly still is not right now; only very few folks or companies use it.
I think its killer use case is actually embedded in non-web places. Tree Sitter parsers require arbitrary programs to be able to parse arbitrary languages. WebAssembly is a natural way to achieve that: write your parser in any language, compile to WebAssembly, use that result in any supported editor. You get sandboxed execution and arbitrary compute.
It has to compete with more domain-adapted use cases though. Does WASM make more sense than eBPF for packet filtering? It doesn't seem to make more sense than JavaScript for making websites. Maybe it makes more sense for deploying edge services (which IIUC is the main use case for WASI).
Plugin architectures are a niche where WASM really shines. Before WASM most plugins were either high performance (loading dynamic libraries) or sandboxed and safe for untrusted plugins (LUA etc). WASM allows you to have your cake and eat it to. You pay with a bit of complexity, but it's in a great and somewhat unique place in the tradeoff space
Many things are possible that weren't possible before. For example, I was able to compile the Dart VM (the compiler + analyzer + VM) to wasm and run it on the web: https://github.com/modulovalue/dart-live it supports hot reload and many other cool features. It runs essentially everywhere and it's a very bare proof of concept for a fully integrated programming development system.
The problem is that things just take time if you have to coordinate across a bunch of languages and teams while trying to make everyone happy.
To give you a sense of what else is coming: the wasm ecosystem is moving towards supporting a component model. Eventually you'll be able to import any piece of code from any programming language that supports it. Wasm interface types will make that possible.
> I was able to compile the Dart VM (the compiler + analyzer + VM) to wasm and run it on the web
Is this really a representative use-case of WASM/WASI? Would'n it be much better to compile Dart to WASM (the Dart SDK even supports "dart compile wasm")?
Your analogy doesn't quite hold. The primary use case of a compilation target is to compile programs, not the compiler itself.
With Dart specifically, "dart compile wasm" already exists precisely for that purpose. Compiling the entire Dart VM (a multi-hundred-thousand-line C++ codebase) to Wasm and then running Dart inside that is a clever in-browser IDE trick, but it's heavy, indirect, and not what Wasm/WASI was designed to showcase. It also sidesteps WasmGC, which is exactly the kind of Wasm evolution that makes Dart-to-Wasm compelling.
I think I've seen you comment this on every recent WASM post, and I'm really wondering what you think breakthrough success looks like for a low-level technology like WASM?
Do you expect everyone to hand-code their websites in WASM? Do you expect every webapp be cross-compiled to WASM?
From where I'm standing, WASM is extremely successful in its specific niches: in enabling islands of high-performance in otherwise web-based software, and in sandboxing plugins to native apps/servers.
It's a silent technology, but I'd argue it has broken through in that most of us already use it daily without knowing. Figma, Google Sheets, Disney+, Prime Video, and much more all have WebAssembly somewhere in their stack.
It's used heavily by major web apps like Figma, it's used to run non-Javascript languages on Cloudflare Workers, many compute-heavy web libraries rely on Wasm modules, many web games rely on Wasm, it's used for safe plugins in some native apps like Microsoft Flight Simulator, amongst other use cases.
I mean, it’s another tool. It doesn’t really make an entirely new kind of web app possible, but it’s useful for some specific compute-heavy tasks (with limitations like JS<->WASM being slow). It’s also useful for running not-JS in the browser; I’m building a lighting console with a web UI distributed over multiple devices, and being able to use the exact same structs/representation and algorithms on server and client is pretty neat. It’s like Node, but in reverse! But none of this is cause for paradigm shift, so I don’t think seeing a ”breakthrough” really is relevant.
Just allowing more than one arraybuffer could go a long way to help with performance. One array buffer for the wasm memory space, then an arraybuffer for each input or output argument.
My task in question was a number crunching task, basically doing multiply-and-add for 336-bit integers. I wrote a JS version, and a C version compiled into WASM by using Zig. You'd think that WebAssembly would trounce JS here, but it actually didn't.
The JS code had been written carefully to avoid allocations, and also avoiding the built-in JavaScript BigInt. I rolled my own BigInt instead using an array of numbers. Each number, despite being a double, was basically a 48-bit integer. Long multiplication requires splitting a 48-bit integer into two 24-bit integers so an intermediate multiplication result will fit in 48 bits.
The C version used 32x32=64-bit integer math. (Would have been nice if WASM had supported 64x64=128-bit multiplication)
Even with the overhead of using doubles instead of integers, the JavaScript and C versions ran at nearly the same speed. I think the C version was slightly faster, but not significantly. The C version took a lot longer to load, as it had to instantiate a Webassembly object, and had to run glue code to copy things in and out of Webassembly memory.
> and had to run glue code to copy things in and out of Webassembly memory.
Not surprising. The FFI boundary is always a bottleneck. If you can eliminate it, you will see where the WASM JIT shines. You have far more control over mechanical sympathy with C/WASM than JavaScript (though far from perfect).
Also, consider publishing your findings and ask for reviews for optimization opportunities.
Wasmtime implements a remote debugging server, so that you can debug guest programs with a recent build of LLDB. Set breakpoints based on the source language symbols, single-step through wasm opcodes, anything you'd expect: https://docs.wasmtime.dev/examples-debugging-guest.html
still useless. I had an idea to offload parts of my game core into wasm leaving only UI in the browser - I abandoned that idea when there was absolutely zero possibility for me to debug in browser what is wrong with my core. i just rewrote everything to TS (from rust)
This! The only way to get to a stable system at least with c/c++ source, where you can hunt bugs, is to have a fairly large unit test coverage. When something fails - add that as test case; run ctest - pray that this is discoverable with tests.
So wasm is a really strange compilation target for systems programming languages.
I mean there _are_ ways to debug it in a browser but they sort of suck.
I'm building a game where you learn to program golang or python and it all runs in webassembly, this way any student chromebook can just pick up and go.
That feels pretty revolutionary, no need to setup your local system to get core concepts.
Even have plans to use postgres in WASM (pglite), and I know a few real time apps use sqlite in WASM.
They still have not fixed their build system. Meson/ninja or cmake would be alternatives. Nothing to have them abandon mozconfig ... this is legacy code. The rest of the world moved on. Mozilla lives in the past.
reply